Move from Salesforce to Attio without the headache

This is the step teams skip, and it is the one that determines whether the migration is clean or messy. A Salesforce org alive for a few years has accumulated custom fields, record types, validation rules and object relationships that made sense at the time and no longer do. Export all of it into Attio and you have recreated the same mess in a new tool.

We run this on a whiteboard with the client before touching Salesforce. The answer almost always cuts the field count by 40 to 60 percent.

• Which objects do you actually need? Contacts, Companies and Deals certainly. Then: which custom objects are load-bearing, and which are dead weight?
• Which fields matter? For each object, which are actively used in reports, automations or daily work? Everything else is a candidate for deletion.
• Which relationships matter? How do records connect, and which of those connections have to come across?

Salesforce gives you two routes. The Data Export tool (Setup, then Data Export) produces a full snapshot on a weekly or monthly schedule — slow but thorough. Data Loader is better for targeted exports of specific objects and fields, and it is what we use on most migrations.

• Export each object you are migrating as a separate CSV: Accounts, Contacts, Opportunities, plus any custom objects you decided to keep.
• Keep the Salesforce IDs in every export. They are what lets you reconnect relationships on the Attio side, and the only reliable key for a later reconciliation.

Build the structure in Attio before importing anything. The mapping is almost always one to one: Salesforce Contacts, Accounts and Opportunities become Attio People, Companies and Deals, and custom objects become custom objects. Recreate Salesforce opportunity stages as statuses on the Deals object, in the same order with the same names, so reporting continuity holds.

• Upload each CSV, map the columns to Attio attributes, and use the Salesforce ID as an external identifier so records can be relinked later.
• Import Companies first, then People linked to Companies, then Deals linked to both. Custom objects last, once everything they depend on exists.
• Spot-check 10 to 20 records after each file.
• For larger datasets or more complex relationships, Attio's API handles bulk imports cleanly — we use it for anything past a few thousand records or several custom objects.

This is where the most time gets saved. Most Salesforce orgs carry dozens of Process Builder flows, Workflow Rules and Apex triggers, and when you actually audit them, half are broken, duplicated or doing nothing. Do not port them. Rebuild from what you need today; Attio's automation builder is simple enough that the essential set takes an hour or two.

Salesforce reports do not translate directly either. Attio reports through views, dashboards and filtered lists, so recreate each report somebody actually uses. You will almost certainly find that around 70% of the reports in the org have not been opened in months.

• Auto-assign new leads to owners.
• Status changes that trigger follow-ups.
• Deal-won notifications.
• Activity logging from email and calendar sync.

Run both systems in parallel for a week: daily work happens in Attio, Salesforce stays read-only as a reference. Then archive Salesforce — but do not cancel the licence yet; keep read access for 30 to 60 days. For a mid-size team under 50 users with a few custom objects, budget two to four weeks end to end. Heavy customisation, or integrations with other systems that need rebuilding, pushes it to six to eight.

• Migrating every field. Move every custom field you ever created and Attio ends up as messy as Salesforce.
• Porting every automation instead of rebuilding the few that matter.
• Skipping the data model conversation — the single most common cause of a painful migration.
• Not mapping the Salesforce IDs. If you ever need to reimport or reconcile, you will regret it.
• Cancelling Salesforce before the parallel week is done.