Interactive calculator
CRM migration calculator: estimate migration complexity before you move
Score CRM migration complexity from record volume, custom fields, integrations, workflows, and data quality.
Introduction
What this calculator is for, and what it is not.
CRM migrations go wrong in a consistent way. The record count looks manageable, the vendor demonstrates an import tool, a date is set, and then the project discovers that the difficulty was never in the records. It was in the two hundred custom fields, the eight systems reading and writing CRM data, and the thirty automations whose behaviour nobody can fully describe.
This calculator scores complexity from the five inputs that actually predict it: record volume, custom fields and objects, connected systems, automations, and data quality. Volume contributes least. Integrations and automations contribute most, because each one is a dependency that has to be understood, rebuilt, tested, and cut over without breaking whatever sits downstream of it.
The score is a planning input, not a verdict. A high score does not mean do not migrate; it means separate the data plan from the workflow plan from the integration plan, and rehearse the rollback before you need it. A low score does not mean it will be easy — it means the known risks are smaller, and the unknown ones still deserve a test run.
The problem
The problem this is trying to surface.
Migration estimates are built on the wrong variable. Record count is easy to measure, so it becomes the proxy for effort — but moving two million contacts is a largely mechanical operation, while untangling forty interacting automations is not. The estimate is confidently wrong in a direction that only becomes visible once the project is underway and the date has been communicated.
The second problem is the dependency inventory nobody has. A CRM that has been in use for five years is read and written by systems that were connected by people who have since left, through integrations that were configured once and never documented. Each one is a live dependency, and the first time most teams see the full list is when something breaks after cutover.
The third problem is that data quality is treated as a cleanup task rather than a mapping problem. Poor quality does not just mean untidy records; it means fields used for purposes they were not designed for, picklists containing free text, and the same concept stored three ways. Every one of those needs a mapping decision made by somebody who knows the intent, and that work cannot be automated away.
You're likely here because
- You are being quoted a migration timeline based on record count alone
- Nobody can list every system that reads or writes your CRM data
- There are automations running that predate everyone currently on the team
- You need to explain to a stakeholder why this is not a weekend job
How the inputs work
What each input does to the result.
Every input is something you supply, so the result is only as good as the honesty of the answers. Knowing how each one is weighted is what makes the output arguable rather than opaque.
Step 01
Estimate record volume
Contacts, companies, deals, tickets, and activities in thousands. This is the input everyone starts with and it contributes the least to real complexity — it is included so you can see how little it moves the score.
Step 02
Count custom fields and objects
Every custom field and object requires a mapping decision from somebody who understands what it was for. This is where undocumented business logic tends to be hiding.
Step 03
Count connected systems
Every application that reads or writes CRM data is a dependency that must be inventoried, rebuilt, tested, and cut over. This input is weighted heavily because it deserves to be.
Step 04
Count automations and workflows
Routing rules, sequences, scoring models, notifications, and sync logic. Each has to be understood before it can be recreated, and understanding is the expensive part.
Step 05
Rate data quality
Higher is cleaner and better governed. Poor quality raises the score because it converts a mechanical migration into a series of mapping judgments.
Step 06
Read the score as a plan shape
High complexity means separate data, workflow, integration, and cutover plans with a rehearsed rollback. Lower complexity still means explicit mapping, validation, and a tested rollback path.
Implementation path
What to do with the result.
- 01
Inventory every custom field, object, workflow, and integration before estimating anything. The inventory itself usually changes the conversation about timing.
- 02
For every field, name the authoritative source and the destination mapping. Fields nobody can explain are candidates for retirement rather than migration.
- 03
List every system that reads or writes CRM data, including the ones connected by people who have left. Each is a cutover dependency.
- 04
Take a representative sample of records — including the messy ones, not just the clean ones — and test the migration and the rollback on it.
- 05
Rehearse the cutover end to end, including what happens if you have to reverse it. An unrehearsed rollback is not a rollback.
- 06
Migrate in stages where the dependency graph allows, and keep the old system readable until the new one has completed a full business cycle.
Controls
Controls that matter.
Control 01
A rehearsed, tested rollback path before any production cutover
Control 02
A documented mapping decision for every custom field and object, made by somebody who knows its intent
Control 03
Permissions and record visibility validated after migration, not assumed to carry over
Control 04
The source system kept readable until the destination has completed a full business cycle
Examples
How teams read this in practice.
Patterns that recur when this is scored honestly, and what each one is actually telling you.
Estimated on record count
A migration is scoped from two million contacts and lands on the eight integrations nobody inventoried. Scoring integrations and automations alongside volume shows where the effort actually sits before the date is committed.
The automation nobody can explain
A scoring model built by a departed employee still routes leads. It cannot be recreated until somebody works out what it does, and that archaeology is project time that belongs in the estimate.
Clean sample, messy reality
A migration tested on tidy records succeeds and then fails on the free-text values sitting in a picklist field. Testing on a representative sample including the messy records surfaces the mapping decisions in advance.
No rehearsed rollback
Cutover goes wrong and the rollback plan exists only as a paragraph. Rehearsing the reversal is what turns an irreversible date into a reversible one, and it is the control most often skipped.
Limitations and considerations
What this tool cannot tell you.
- This is a directional complexity score, not an estimate of hours or cost. Two migrations with the same score can differ substantially depending on how much undocumented logic exists.
- The weighting is a simplification. In some organizations a single deeply embedded integration dominates every other factor.
- Data quality is self-rated, and teams consistently rate their own data higher than a sample inspection supports.
- The score says nothing about organizational readiness, change management, or whether the destination CRM is the right choice.
- Regulatory, retention, and residency obligations attached to CRM data are not modelled here and may constrain how a migration can be run.
- A low score is not permission to skip mapping, validation, or rollback rehearsal. It means the known risks are smaller, not that there are none.
FAQ
Questions about this tool.
Why does record volume barely move the score?
Because moving records is largely mechanical. Untangling interacting automations and rebuilding eight integrations is not. Record count is the easiest thing to measure, which is exactly why it becomes the wrong proxy for effort.
What counts as a connected system?
Anything that reads or writes CRM data — marketing platforms, support tools, billing, data warehouses, internal scripts, and the integration somebody set up four years ago and never documented. Each is a cutover dependency.
How do I rate data quality honestly?
Inspect a sample rather than relying on impression. Look for free text in picklists, the same concept stored several ways, and fields used for purposes they were not designed for. Teams reliably rate their data cleaner than a sample supports.
Does a high score mean we should not migrate?
No. It means the plan needs to be shaped differently: separate data, workflow, integration, and cutover plans, with a rehearsed rollback. High complexity is manageable when it is acknowledged before the date is set.
Can we migrate in stages?
Often, where the dependency graph allows it. Staging reduces blast radius considerably, but it requires knowing which systems depend on which objects — which is why the inventory comes first.
What is the most commonly skipped step?
Rehearsing the rollback. A rollback plan that has never been executed is a paragraph, not a control, and it is the difference between a reversible cutover and an irreversible one.
Related pages
Continue from here.
Start with ARIA
Ask ARIA to act on the result.
A score is a starting point. Describe the outcome you want and ARIA works out the capabilities, systems, and data needed to get there.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Inventory the dependencies before you set the date.
Describe the migration on the public ARIA path, or score whether the operating foundation around the CRM is ready for the move.