Migrate from Ziggu to Salesforce Sales Cloud

Ziggu clients map directly to Salesforce Contacts when a company association exists. The contact's primary project assignment is preserved in a custom field (Primary_Project__c) for relationship continuity. Multi-project clients get multiple Project__c junction records. If a client belongs to multiple projects, each association creates a Project__c junction record, preserving all relationships. The AccountId is set by matching the Ziggu company name to a Salesforce Account or creating one if missing.

Ziggu clients without a resolved company name or project assignment route to Salesforce Lead. Lead status is set to 'Open - Not Contacted' by default; your team defines qualification criteria post-migration. These Leads capture Ziggu client name, email, and phone in Lead fields. Once your sales team qualifies a Lead, it can be converted to a Contact and Account via Salesforce's Lead conversion process, preserving the Source_System_ID__c for audit traceability.

Ziggu client company names become Salesforce Accounts. The Account record is created before Contacts so Contact.AccountId foreign keys resolve correctly during migration sequencing. Account.Phone and Account.BillingAddress carry over from Ziggu contact details. If the company name matches an existing Account, the existing record is used to avoid duplication. Additional custom fields such as Industry, AnnualRevenue, and Project_Status__c are populated where data is available, providing a richer Account profile in Salesforce.

Ziggu projects without an associated client company become Salesforce Accounts tagged with a Project_Origin__c flag. This preserves project-level metadata (status, timeline, budget) as custom fields on the Account record. Parent Account hierarchy is used if Ziggu has a project-grouping structure.

Each Ziggu unit within a project becomes a Salesforce Opportunity. Opportunity Name carries the unit identifier (e.g., 'Unit 4B - Riverside Quarter'). Opportunity Stage maps from Ziggu unit status (Reservation, Contract, Handover). Amount pulls from Ziggu Financials for the unit.

Ziggu units carrying granular attributes — floor, area, bedrooms, facing direction, finish level — that have no direct Salesforce Opportunity field equivalent migrate to a custom Project_Unit__c object linked to the Opportunity via WhatId. This prevents field overcrowding on the Opportunity page layout.

Ziggu conversation threads become Salesforce Tasks. The Task WhoId links to the Contact, WhatId links to the related Project Account or Opportunity. Original message timestamps and participant information are preserved in Task description and custom datetime fields. The Task Subject field captures the conversation title, and any file attachments are linked via ContentDocumentLink to the same WhatId, keeping all context together in Salesforce.

Ziggu files are re-uploaded to Salesforce Files, attached via ContentDocumentLink to the relevant Account, Contact, or Opportunity. File size limits (Salesforce default 25MB per file) apply; oversized files are flagged before the migration run. Version history is preserved where available.

Ziggu payment schedules and invoice records map to a custom Payment_Schedule__c object linked to the Opportunity. Each payment milestone becomes a record with amount, due date, and status. Paid-to-date totals are calculated or stored as custom currency fields. If a payment includes multiple line items, each line can be represented as a separate Payment_Schedule__c record, and a roll‑up summary field on the Opportunity can display the total paid amount.

Ziggu approval records (who approved, when, what was approved) have no direct Salesforce equivalent. Approval data migrates as a custom Approval_History__c object on the relevant record for audit reference. Actual approval logic must be rebuilt as Salesforce Approval Processes or Flow.

Ziggu users are matched to Salesforce Users by email address. Unmatched users are flagged as 'Ziggu_User_ID__c' custom records so owner assignment can be resolved manually before migration. Records without an owner land on a designated fallback Salesforce user. If an unmatched user is later added to Salesforce, FlitStack can re‑run the owner resolution step to reassign their records, ensuring accurate ownership throughout the CRM.