Migrating from Salesforce to a custom CRM: the inventory before the export
An export gives you rows. A migration has to carry everything your team relies on without knowing it. This is the list we make before any data moves.
By David, The Goodstack Company. Updated 2026-09-18.
Why the export is the easy part
Salesforce will give you your data. The Data Export service and the APIs produce files for every object you ask for. That takes hours.
What takes weeks is everything around the rows. Which records point to which. Who was allowed to see what. What happened automatically when a stage changed. Which other systems were quietly reading from Salesforce every night. None of that is in the export, and all of it is part of how your company works.
This guide covers leaving Salesforce for a system you own. It is an inventory. It sets no timetable. We do not give migration timelines before the inventory exists, and you should be careful with anyone who does.
The seven inventories
Make each one a spreadsheet tab. One row per item. For every row, record an owner and one of three decisions: carry over, rebuild differently, or leave behind.
1. Relationships
List every object you use, standard and custom, and how they connect. Accounts to contacts is obvious. The ones that hurt are less visible: a custom object that links an account to a territory, a junction object between products and price books, a lookup someone added three years ago that a report depends on.
- Every object with a record count
- Every lookup and master-detail relationship
- Record types, and what each one changes
- Fields that are required, unique or used as external IDs
2. History
Decide what history has to come with you and in what form.
- Activities: tasks, events, logged calls and emails
- Field history tracking, where it is switched on
- Stage history on opportunities
- Notes, Chatter posts and case comments
Some history needs to be live and searchable on the account. Some only needs to exist in an archive you can open during a dispute. Those are different amounts of work, so decide per item.
3. Files
Attachments and Files are stored separately from records and are the most common thing to be forgotten. List the volume, the file types, and which records they hang from. Check for files that matter legally, such as signed agreements, and confirm where the signed original really lives.
4. Permissions
Write down who can see and change what, in plain language, before you look at how Salesforce implements it. Profiles, permission sets, roles, sharing rules and territory rules are the mechanism. What you need to carry over is the intent.
- Which roles exist in the business
- What each role may see, edit, approve and export
- Records that are restricted for a reason: pricing, personal data, legal holds
This is the inventory most likely to show that nobody knows the current rules. That is worth finding out now.
5. Automation
Everything that happens without a person doing it.
- Flows, and any remaining Process Builder or workflow rules
- Apex triggers and scheduled jobs
- Validation rules and assignment rules
- Approval processes
- Email alerts and templates
For each one, write one sentence: what business rule does this enforce? A lot of old automation protects against a problem that no longer exists. A custom system lets you keep the rules that matter and drop the rest, but only if you know which is which.
6. Integrations
Every system that writes to Salesforce or reads from it.
- Connected apps and installed packages
- Middleware and scheduled syncs
- The ERP, accounting, marketing, support and data warehouse connections
- Spreadsheets that someone uploads by hand every month
For each, note the direction, the frequency, the owner on the other side, and what breaks if it stops for a day. Integrations decide the order of a cutover more than anything else.
7. Reports
List the reports and dashboards people open, not the ones that exist. Usage data will show you that most are never opened. For the ones that matter, record who uses them, for what decision, and which fields they depend on. Those fields are the ones you cannot afford to get wrong.
Reconciliation: how you know it worked
Agree on the acceptance checks before the first test load.
| Check | What it proves |
|---|---|
| Record counts per object, source against target | Nothing was dropped or duplicated |
| Totals on money fields, by period and by owner | Values survived type and currency changes |
| A sample of accounts reviewed by the rep who owns them | The record looks right to the person who knows it |
| Every integration run once in each direction | Connected systems still agree |
| One full workflow performed from start to finish by a real user | The system does the job, not just holds the data |
| A role-by-role login test | People see what they should and nothing more |
Write down who signs each check. A migration without named sign-off is a migration nobody accepted.
Run both systems on purpose
Plan a period where Salesforce and the new system run side by side for one team. Decide in advance which one is the system of record during that time, how changes flow between them, and what ends the period. Parallel running that nobody designed is how records drift apart.
Keep a way back. Until the acceptance checks pass, you should be able to return the pilot team to Salesforce in a day.
What to leave behind
A migration is the one moment when deleting things is cheap. Fields nobody fills in. Objects from a project that ended. Automation that guards against a problem you no longer have. Every row marked "leave behind" makes the new system smaller, faster to build and easier to maintain.
Common mistakes
- Treating the export as the plan. Rows without relationships, permissions and automation are not a working system.
- Migrating everything. It doubles the work and carries the old mess into the new system.
- Forgetting the quiet integrations. The nightly job nobody remembers is the one that stops invoicing.
- Setting a date before the inventory. The inventory sets the date.
- No named sign-off. If nobody accepts the migration, everybody disputes it.
Using this with us, or without us
This inventory is useful whatever you decide, including staying on Salesforce. If you want help, we do it with you as the second step of our process, after a discovery call, and you keep the result.