October 21, 2026

SugarCRM to Salesforce Migration: A Practical Guide with Data Mapping

In Brief: A SugarCRM to Salesforce migration works best in three phases: core records first (Accounts, Contacts, Leads, Opportunities and Cases), then activities (Emails, Calls, Meetings, Tasks and Notes), then files. Before any data moves, store every Sugar record ID in a Salesforce External ID field so each load can be safely re-run as an upsert, and agree a field-level mapping that converts Sugar's dropdown keys, multi-select values and relationship tables into Salesforce picklists and lookups. This guide includes the mapping tables for all three phases.

Most teams leaving SugarCRM (now rebranded as SugarAI) for Salesforce expect the export to be the hard part. It isn't. The real difficulty is that the two platforms model the same business differently, and Salesforce has its own rules about what it will accept, so every difference has to be resolved in a mapping document before the first record moves.

This guide sets out a recommended three-phase approach and a SugarCRM to Salesforce data mapping standard you can adapt to your own org. For a related move, see our guide on how to migrate from Zoho to Salesforce without losing data or automations. Whatever the source system, the principle holds: settle every mapping decision before anyone presses import.

SugarCRMSalesforce

Phase 1

Core records

Phase 2

Activities

Phase 3

Files

Why SugarCRM to Salesforce Migrations Go Wrong

A lot of Sugar's structure lives in places a simple export won't show. Custom fields sit in a separate _cstm table for each module with custom fields, relationships live in join tables such as accounts_contacts, and soft-deleted records marked deleted = 1 are still in the database. Miss any of these and data is silently lost or resurrected. Sugar's team sets also have no direct equivalent in Salesforce, where visibility comes from the role hierarchy, sharing rules and territories.

That's why the most reliable starting point is a full database backup rather than module-by-module CSV exports. On-premise installations have direct access to one. For cloud-hosted instances, check with SugarCRM whether a backup is available under your plan; if it isn't, extract the data through the Sugar API instead.

None of this is a reason to delay a migration. It's a reason to clean and map the data first, the argument we made in why clean data matters more than which platform you choose.

The 3-Phase SugarCRM to Salesforce Migration Approach

Salesforce enforces relationships at load time: a Contact can't point to an Account that doesn't exist yet. Splitting the migration into three phases follows that dependency chain and gives each phase its own checkpoint. Each phase is loaded into a sandbox first (a Partial Copy or Full Copy sandbox, since Developer sandboxes hold very little data), reconciled against Sugar, and only then repeated in production. It's the same phased structure Loncom uses on every CRM migration, whatever the source system.

Global Mapping Rules Before You Start

These rules apply to every object in every phase. Agree them first, because changing one later means reloading data. In the middle column, the value before the arrow is how Sugar stores the data and the value after it is where it lands in Salesforce; the last column explains what goes wrong if the rule is skipped.

Rule	SugarCRM → Salesforce	Why it matters
1Legacy ID	SugarCRM → Salesforceid→Sugar_ID__cExternal ID, Unique	Lets you re-run a load without creating duplicate records
2Custom fields	SugarCRM → Salesforce*_c<module>_cstm→custom `__c` fields	Skip this and every custom field is silently left behind
3Picklists	SugarCRM → Salesforcekeys^A^,^B^→picklist valuesA;B	Prevents values like "P1" arriving where your team expects "High"
4Deleted records	SugarCRM → Salesforcedeleted = 1→Not migrated	Stops records your team deleted from coming back
5Owners	SugarCRM → Salesforceassigned_user_id→OwnerIdNeeds "Update Records with Inactive Owners"	Keeps every record assigned to the right person, including people who have left
6Audit dates	SugarCRM → Salesforcedate_entereddate_modified→CreatedDateLastModifiedDateNeeds "Set Audit Fields upon Record Creation"	Keeps original creation dates, so history and reports stay accurate

With Sugar's ID in an External ID field, every load becomes an upsert: re-running it updates the records it already created instead of duplicating them. It's the same principle behind designing a two-way sync without duplicates, and it matters just as much for a one-off move.

'The most dangerous button in a CRM migration is "Run import" the second time,' says Stefan Loncar, CEO of Loncom Consulting.

Phase 1: Accounts, Contacts, Leads, Opportunities and Cases

Start by matching Sugar users to Salesforce users, because every record's owner depends on that table, then load objects in the order below. If a group of Sugar custom fields describes a separate thing, such as a subscription or a site, it may belong on its own object rather than on Account, a decision we cover in when standard CRM objects aren't enough; the same logic applies to custom objects in Salesforce.

SugarCRM (load order)	Salesforce	Note
1Users	User	Matched, not migrated: build the ID mapping first
2Accounts	Account	Parent accounts linked in a second pass
3Contacts	Contact	Account link from `accounts_contacts`
4Leads	Lead	Unconverted leads only (recommended)
5Opportunities	Opportunity + Contact Roles	Roles from `opportunities_contacts`
6Cases	Case	Case number kept in a legacy field

Fields that need transformation

Standard fields such as names, titles and phone numbers map one-to-one. These are the ones that don't:

SugarCRM field → Salesforce field	Salesforce field
Account employees, annual_revenue	→ NumberOfEmployees, AnnualRevenue Text converted to numbers
Contact email_addresses (primary flag)	→ Email + HasOptedOutOfEmail Stored in a separate table, not on the contact
All addresses state, country	→ StateCode, CountryCode Only if State and Country picklists are on; free text must match picklist values
Lead account_name	→ Company Required, so blanks need a placeholder
Opportunity sales_stage	→ StageName Required; each Sugar stage mapped to a picklist value
Case case_number	→ Legacy_Case_Number__c CaseNumber is generated by Salesforce
Case priority (P1, P2, P3)	→ Priority (High, Medium, Low) Sugar keys mapped to Salesforce labels

Converted leads: their data already lives on as Contacts, Accounts and Opportunities, so migrating them again would duplicate records and add noise to lead reports. Migrating unconverted leads only is the cleaner option. Revenue Line Items (in Sugar editions that use them) map to Opportunity Products but need Products and a Price Book first, so treat them as optional scope unless reporting depends on them.

Phase 2: Emails, Calls, Meetings, Tasks and Notes

Sugar keeps Calls and Meetings as separate modules; Salesforce splits activities into Tasks and Events. For every activity, Sugar's parent_type and parent_id map to WhatId for Accounts, Opportunities and Cases, and to WhoId for Contacts and Leads. Activities linked to several Contacts need Shared Activities enabled first.

SugarCRM → Salesforce	Salesforce	Key rule
Calls	→Task subtype Call	`duration_hours` + `duration_minutes` → CallDurationInSeconds `direction` → CallType
Meetings	→Event	`date_start`, `date_end` → StartDateTime, EndDateTime Attendees → EventRelation
Tasks	→Task	Status Pending Input → Waiting on someone else Other statuses match by name
Notes (text)	→ContentNote Enhanced Notes	Linked to records through ContentDocumentLink
Emails	→EmailMessage Enhanced Email	Body from `emails_text` Linked records from `emails_beans`

EmailMessage or Task: EmailMessage keeps the full email, recipients and HTML body on the record; a Task with type Email is quicker to build but flattens each email into a subject and plain text. Email history is where migrations easily lose context, so make it a deliberate choice; we covered a related problem in what moves, what breaks and what to rebuild in a Mailchimp migration.

Phase 3: Files and Attachments

Sugar stores file contents in its upload folder, not the database, so this phase needs a copy of that folder alongside the data export.

SugarCRM source → Salesforce	Salesforce target	Linked to
Notes with an attachment	→ContentVersion	The note's parent record, via ContentDocumentLink
Documents and revisions	→ContentVersion	Each related Account, Contact, Opportunity or Case
Email attachments	→ContentVersion	The migrated EmailMessage

If a note has both text and an attachment, its text goes into a separate ContentNote, or the file's description for short notes, so nothing is lost. Set ShareType and Visibility on every ContentDocumentLink, and check file storage before loading.

Finally, review everything that connects to the CRM: as we covered in the setup decisions that make or break two-way sync, integration settings decide whether a sync holds after go-live.

Planning how you'll report on your data once it's moved?

Explore Salesforce CRM Dashboards

Testing and Validation Checklist

Run these checks after each phase, wherever they apply.

✓ Dry run in a sandbox Load the full phase into a sandbox (Full Copy where data volume requires it) before any production write.		✓ Record counts reconcile Sugar counts for everything in scope match Salesforce per object.

✓ Relationships hold Spot-check accounts with their contacts, opportunities and activities in both systems.		✓ Owners and dates are right Owners map to the correct users and original created dates survived.

✓ Picklists are clean No unmapped Sugar keys landed as unexpected picklist values.		✓ Files open Sample files from every parent type open and sit on the right record.

One more test is worth running on purpose: load the same phase twice. If the second run creates new records, the legacy ID rule isn't applied somewhere. It's the principle at the heart of how we finished an Insightly to HubSpot migration.

In Short

A SugarCRM to Salesforce migration succeeds or fails on its mapping. Load core records, then activities, then files; carry Sugar's IDs into External ID fields so every load can be re-run safely; and reconcile each phase in a sandbox before production. After go-live, keeping the data accurate is an ongoing job, which is where a CRM data quality framework takes over.

Planning a move from SugarCRM to Salesforce?

Book a Free Consultation

FAQ

How do you migrate from SugarCRM to Salesforce?

Move the data in three phases, each depending on the one before: core records, then activities, then files. Keeping every Sugar ID in an External ID field lets each load be safely repeated, and testing each phase in a sandbox catches mapping errors before they reach production.

How do you migrate SugarCRM attachments to Salesforce Files?

Note attachments, Documents and email attachments are loaded as ContentVersion records and linked to their parent records with ContentDocumentLink. Because Sugar stores file contents in its upload folder rather than the database, that folder has to be exported alongside the data.

Can you keep the original created dates when migrating to Salesforce?

Yes. With "Set Audit Fields upon Record Creation" enabled, CreatedDate, CreatedById, LastModifiedDate and LastModifiedById can be set when records are first inserted, so Sugar's original dates carry over. It has to be enabled before the load, because these fields can't be changed afterwards.

How long does a SugarCRM to Salesforce migration take?

It depends on record volume, the number of custom fields and modules, and how many files need to move. Agreeing the mapping and running sandbox tests usually takes longer than the production load itself, so timelines are best set after an audit of the Sugar instance.

How does Loncom approach a SugarCRM to Salesforce migration?

The same way we approach every CRM migration, drawing on 150+ CRM implementations: an audit of the source system first, a field-level mapping document agreed with your team, then a phased load where each phase is tested in a sandbox and reconciled before production. You can read more about how we deliver Salesforce implementation and optimisation.

Back to Loncom Work