Migrations are usually justified on the difference between two licence fees. That difference is the smallest cost involved, and the ones that dominate are rarely in the business case.
The licence is the visible part
Comparing two annual fees is easy, which is why it anchors the decision. Both numbers are known, quoted and defensible.
Everything else in a migration is an estimate produced by people who have an interest in the project happening.
That asymmetry biases every business case in the same direction. The certain saving is compared against optimistic costs.
A useful correction is to treat the internal effort estimate as a lower bound and plan against a multiple of it.
The multiple most teams converge on after a few migrations is somewhere between two and three.
Historical data rarely moves cleanly
Every platform stores history in its own structure, and export formats are designed for backup rather than for import elsewhere.
Some fields have no equivalent in the destination. Others exist but are calculated differently, which is worse because the mismatch is invisible.
The common compromise is to migrate a limited window of history and keep the old system in read-only mode for the rest.
Read-only mode is often not free, and the licence for it can persist for years past the migration.
Where the old system is switched off entirely, the practical outcome is that year-on-year comparison breaks for a full cycle.
Definitions change and reporting breaks
Two analytics tools counting the same event will produce different numbers, because a session, a visit and a user are defined by rules that differ between vendors.
Those rule differences are documented and nobody reads the documentation until the numbers disagree.
When they disagree, the immediate assumption is that the new tool is broken. Sometimes it is, and more often it is measuring a slightly different thing correctly.
Resolving that requires someone to compare methodologies line by line and produce a written statement of what changed.
If that document is not produced, every subsequent argument about performance includes a dispute about the numbers, indefinitely.
Integrations are the long pole
A tool in isolation is straightforward to stand up. A tool sitting in the middle of six connections is a different exercise.
Each connection has its own authentication, its own rate limits and its own failure behaviour, and each is owned by someone different.
Connections built years ago are usually undocumented, and the person who built them has often left.
Discovering what depends on the old system is itself a project, and it is normally discovered by breaking something.
Planning a migration without an inventory of downstream consumers guarantees at least one surprise outage in a report somebody senior reads.
The parallel running period
Running both systems together is the responsible approach, and it means paying twice while doing double the work.
The period is always longer than planned, because the decision to switch off requires confidence that only accumulates slowly.
During parallel running, discrepancies between the systems have to be investigated rather than ignored, which consumes analyst time continuously.
Teams that skip parallel running save that cost and pay a larger one later, usually at a quarter end when a number cannot be reconciled.
A defensible plan budgets for at least one full reporting cycle in parallel, including whatever the longest cycle in the business is.
Attention is the real budget
The scarce resource in a migration is not money, it is the attention of the three or four people who understand how the current setup actually works.
Those people are also the ones doing the most valuable ongoing work, so their time is drawn from campaign performance rather than from slack.
The opportunity cost is invisible because nothing appears on a ledger. Campaigns are simply managed less closely for a quarter.
That reduction in attention often costs more than the entire licence saving, and it is never attributed to the migration.
Estimating it honestly means asking what those people would otherwise be doing and accepting that it will not happen.
When a migration is worth it
The clear cases share a property. The current tool blocks something the business needs to do, rather than being merely inferior.
A platform that cannot support a required data structure, or cannot be accessed by a team that needs it, is a genuine constraint.
Cost savings alone rarely justify it once the full cost is counted, unless the saving is very large or the current contract is ending anyway.
Contract renewal dates are the natural trigger, because the switching cost is paid at a moment when the alternative is also being negotiated.
Migrations started mid-contract, on enthusiasm for a better interface, are the ones that stall halfway and leave two systems running.
Pricing it honestly before you start
A defensible estimate has four lines beyond the licence. Data migration, integration rebuild, parallel running and lost attention.
Each can be estimated roughly, and rough estimates in the right order of magnitude beat precise estimates of the wrong quantity.
It also helps to name the point of no return in advance, the moment after which reverting costs more than continuing.
Projects without that marker tend to drift past it unnoticed and then continue on the grounds that too much has been invested.
Writing the estimate down before the decision also creates the only reliable input to the next migration, which is a record of how wrong the last one was.