Migration changes where things run. Modernisation changes what you can change next.
The two words get used as if they were the same purchase. They are not. Migration changes where your systems run. Modernisation changes what your business can change next. Most programmes buy the first and put the second on the invoice, and the work tells the truth long after the steering deck does.
I watched a manufacturer “modernise” by lifting a fifteen-year-old ERP onto a cloud VM. New datacentre, new hosting bill, the same four hundred stored procedures nobody dared touch. Eighteen months later the same change request still took three weeks, because the thing that made it slow was never the hardware. They are mid-rewrite now, at roughly two-and-a-half times the lift-and-shift budget, and the variant that once took three weeks ships in two days. That gap is the whole argument.
Migration moves the boxes. Modernisation moves the problem into places you can actually change: the boundaries, the data model, the rules themselves. If your programme leaves all three where they were, you have paid to relocate the constraint, not to remove it. That is the honest difference between a lift-and-shift and a replatform, and it is worth settling before anyone signs.
The velocity test, and why you should not trust it alone
There is a test people reach for. Pick the change that hurts most today (a new product variant, a second legal entity, a pricing rule due this quarter) and ask how long it takes after the programme lands. Same as before, you migrated. Faster, you modernised.
Useful, but do not trust it alone. A near-zero change rate can mean a stable system, or it can mean the organisation stopped asking because asking always hurt. Learned helplessness looks identical to maturity from the outside. Velocity is one input. Security posture, vendor end-of-support, and the one person who reads those stored procedures retiring next year are independent reasons to act, and none of them show up in a change-lead-time chart.
Why modernisation costs two to three times a migration
Here is the part the budget forgets. Modernisation costs two to three times a migration because you are re-deriving decisions the old system froze. The people who made them are gone, the documentation was never written, and the rules now live as archaeology inside procedural code. You are not porting logic. You are reconstructing intent. Get the new boundaries wrong and you ship the old mistakes with fresher paint.
So budget for parallel running in quarters, not weeks, and model the real failure mode rather than the happy path: a half-finished rewrite leaves you with two systems that both half work. That is more expensive than either the old system alone or the new one finished, and it is the state a badly scoped programme spends the longest in.
The frozen decision nobody can explain
And I should weigh my own bias openly, because I sell modernisation. Last year I told a client to leave a billing system alone. Its change rate was low, but we probed why, and the stability was genuine: a stable product, no frozen fear underneath it. A clean lift was the cheaper, safer call, and pretending otherwise would have been selling them the more expensive answer because it was the one I profit from.
The scoping question I would sit with is not the velocity number. It is this: which frozen decision in your current system can nobody on the team actually explain anymore? That blank spot is your real modernisation scope: the place where migration will change nothing and only subtraction and re-derivation will. If you are about to fund a programme sold as modernisation but scoped as a move, that is the moment to stop. Talk to TrueForge and we will help you tell which one you are actually buying.