Migrate from Sage CRM to Salesforce Sales Cloud

Sage CRM Company is the primary account record holding company name, address, industry classification, and territory data. It maps directly to Salesforce Account. The CompanyID external identifier is preserved as a custom field sage_company_id__c for reconciliation. We extract from Sage CRM via SQL query or REST API and insert into Salesforce using Bulk API with Account as the parent object loaded before any dependent Contact records.

Sage CRM Contacts link to Companies via PrimaryCompanyLink foreign key. All standard fields plus custom Contact fields migrate. We resolve PrimaryCompanyLink to the Salesforce AccountID at migration time using the sage_company_id__c external ID as the lookup anchor. Duplicate detection can be enabled via Salesforce Match Rules during import if the customer has Sage CRM match-rule configuration to replicate.

Sage CRM uses a separate Lead entity distinct from Contacts, with its own lifecycle stages, qualification fields (LeadSource, Status, Rating), and source tracking. All standard and custom Lead fields map directly to Salesforce Lead. The LeadID is preserved as sage_lead_id__c. If the customer uses a lead-to-contact conversion process, we document the mapping to Salesforce's Convert action for the admin to configure post-migration.

Sage CRM Opportunities track pipeline stages, revenue amounts, expected close dates, and owner assignments. Multi-currency amounts migrate with CurrencyIsoCode preserved. Stage values map to a Salesforce Sales Process that we configure in the destination org before migration. Closed-won and closed-lost reasons from Sage CRM custom fields map to Salesforce Loss Reason and custom win-reason fields. The Opportunity's Company link resolves to AccountId using the same external-ID lookup strategy.

Sage CRM Cases are the service and ticket object with severity, status, and assignment fields. Case-threaded communications stored in the Communication table are linked by case ID. We export Cases as Salesforce Cases and then export related Communication records separately, linking them to the Case via WhatId on the Task or EmailMessage record. Case number from Sage CRM is preserved in a custom field sage_case_number__c.

The Communication table is entity-type agnostic in Sage CRM, storing emails, call logs, and meeting notes linked to any entity type (Company, Contact, Lead, Opportunity, Case) by entity type code and entity ID. We split Communications by type: email-type records migrate to Salesforce EmailMessage (body) plus a linked Task; call logs migrate to Task with TaskSubtype=Call; meeting notes migrate to Event. We resolve the WhoId (Contact or Lead) and WhatId (Opportunity, Account, or Case) by cross-referencing the Sage CRM entity type and entity ID against the migrated Salesforce record IDs using a lookup table built during the migration.

Sage CRM supports user-defined Custom Entities each with their own fields and relationships. We inspect the entity schema via the Sage CRM REST API model service, reading both the display name and the internal table name (which differs from the UI name). We pre-create the Salesforce custom object with the matching __c API name in the destination org before any data loads. Custom entity relationships to Companies, Contacts, or Opportunities migrate as lookup or master-detail fields on the custom object, resolving parent IDs using the external ID lookup table constructed during Account and Contact migration.

Sage CRM Users have role-based security profiles controlling object and field access. We export user accounts with role assignments, security profiles, and email addresses. Users must be manually provisioned in Salesforce by the customer's admin before migration because Salesforce requires active User licenses per seat. We map Sage CRM user email to Salesforce User email as the matching key. Any Sage CRM user without a corresponding Salesforce User is held in a reconciliation queue for the admin to address before record import proceeds.

Sage CRM workflow rules are stored as database records with embedded ASP-script logic, escalation triggers, and action definitions. These cannot be extracted as portable configuration and have no Salesforce equivalent that can be rebuilt automatically. We produce a complete written inventory of every active Sage CRM workflow documenting its trigger conditions, conditions, actions, escalation rules, and recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner uses this inventory to rebuild the five to ten highest-business-impact workflows first. Workflows are explicitly out of scope for data migration.

Sage CRM reports are stored in the Sage CRM report schema and reference entity fields by internal database IDs. We export report definitions and data. Report formatting, formula logic, and scheduling do not migrate. We deliver a report mapping document listing each Sage CRM report with its equivalent Salesforce Report type, filters, and grouping so the customer's admin can recreate reports in Salesforce Reports and Dashboards. For large reporting estates, we recommend scheduling a separate reporting-rebuild engagement.

Sage CRM role-based security profiles control object and field visibility. We map Sage CRM role names to Salesforce Profiles and Permission Sets based on the customer's role structure. Field-level security migrates by documenting which custom fields require read-only or hidden status per role. Profile assignment is done by the customer admin; we provide the mapping document and validate that migrated users have the correct Profile in Salesforce post-migration.

Historical created dates and last modified timestamps from Sage CRM must be explicitly preserved in Salesforce because Salesforce sets CreatedDate to the import time by default. We use the Salesforce Bulk API with the useSerialMode option and explicit CreatedDate/LastModifiedDate field mapping to preserve the original timestamps. This is a pair-specific high-priority requirement confirmed in the DecisivEdge case study where historical data accuracy was cited as the primary migration challenge.