Why your CRM migration keeps slipping
Migrations rarely fail on the technical work. They fail because the old system encoded business rules nobody wrote down.
Key takeaways
- Estimates are built on the data model; overruns come from undocumented business logic.
- A two-week archaeology phase typically removes six weeks from the back of the project.
- The discovery output should be a list of behaviours, not a list of tables.
What actually causes CRM migrations to slip?
Undocumented business logic. The data model is knowable and easy to estimate; the automations, validation rules and reporting conventions layered on top of it over years are not. Every one discovered after the estimate becomes a change request, and they arrive in the last third of the project.
The estimate and the overrun measure different things
Every CRM migration estimate is built on the data model. Every CRM migration overrun is caused by the business logic hiding in it.
The field called status_2 that three people in finance rely on. The automation someone built in 2019 that silently reassigns leads over a certain value. The report that only works because of a data-entry convention nobody documented.
Archaeology before architecture
We now start migrations with a two-week archaeology phase. We instrument the old system, watch what actually gets read and written, and interview the people whose workflows depend on it.
The output is a list of behaviours, not a list of tables. It adds two weeks to the front of the project and typically removes six from the back.
What the behaviour inventory captures
| Category | Example | Why it breaks migrations |
|---|---|---|
| Hidden automations | Lead reassignment above a value threshold | Silent behaviour change after cutover |
| Convention fields | Status held in a free-text field | Reports fail with clean data |
| Shadow integrations | A spreadsheet syncing nightly | Nobody owns it until it stops |
| Permission carve-outs | One team with edit rights on closed records | Blocks month-end after go-live |
Cut over by capability, not by date
Big-bang cutovers concentrate every unknown into one weekend. We sequence by capability instead — pipeline first, then quoting, then reporting — with both systems reconciled daily until the last capability moves.
It costs a few weeks of parallel running and it removes the scenario where a discovered behaviour becomes an incident instead of a ticket.
FAQFAQ
Frequently asked questions
About the author
Sofia runs delivery across engineering engagements — discovery, estimation, increments and handover. She writes about migrations, pricing models and the undocumented business logic that turns a clean estimate into an overrun.
- Enterprise migrations
- Project estimation
- Delivery management
- CRM and ERP systems
