Services · legacy modernization
The deadline that forces this is in somebody else's calendar.
Modernisation is rarely a decision about code quality. It is a date somebody else set — a vendor ending support, a store changing its rules, a runtime losing its security updates — and the only variable you control is whether you meet it calmly or at three weeks' notice.
So this page starts with the dates rather than with our method. If none of them applies to you, the honest recommendation is further down and it is to do nothing.
Currently in force
The cliffs that are actually moving budgets right now
Not a general argument about technical debt. Specific dates, from vendors' own support policies, that decide whether an application can still be shipped, updated or patched.
Diagnosis
Four kinds of legacy, three of which are worth money
- The framework died. The vendor has stopped shipping it, or ships it without security updates. Xamarin and CUBA Platform are the two we meet most often. This one has a date attached and the date is not negotiable.
- The platform changed its rules. App stores raising target API levels, browsers dropping a plugin, a payment scheme deprecating a protocol, TLS versions going away. Your code did not change; the ground under it did.
- The people left. Nothing technical is wrong. Nobody who remains can change it safely, so nobody changes it, so it slowly stops matching the business. The expensive version of this is discovered when somebody finally tries.
- It cannot be deployed any more. Manual releases, a server nobody dares reboot, no reproducible build, no path into a container. Often the real blocker behind "we cannot move quickly" — and the one that is fixed without touching the application at all.
Before any plan
An assessment you could hand to a different supplier
Nobody can price a migration of a system they have not read. The assessment is a separate, fixed-fee engagement and it produces two documents rather than a proposal:
- A technical report. The methodology used, the evidence base, the established root cause of what is actually failing, the associated defects, the information-security risks found on the way past, a remediation plan, and estimated figures marked as estimates.
- A section on what it could not establish. Usually because the data was not there. An assessment with no limitations section has either not looked hard enough or is not telling you something.
- An implementation instruction. Step by step, per infrastructure node and software component, with a verification procedure, a rollback procedure, test scenarios and an acceptance checklist — written for your engineers.
Both documents are yours. Take them to another supplier, to the platform vendor, or to your board. We have signed engagements where we assess and somebody else implements, and that boundary sits in the contract rather than in a reassurance.
The migration itself
In waves, with the old system still running
01 · The dated risk first
Whatever has a calendar entry attached — an unsupported runtime, a store cut-off, an expiring certificate. These do not negotiate and they do not care about the sprint plan, so they go first regardless of what is most interesting.
02 · Nothing goes dark
Users keep using the system while it changes underneath them. On the payment application we maintain, the framework migration happened with people paying through it — which is the standard, not an achievement to be celebrated.
03 · Side by side, not a switch
Old and new run together while traffic moves across in increments you can reverse. A migration that depends on a single cut-over weekend is a migration with one chance, and that is a planning choice rather than a technical fact.
04 · The rollback written first
Before the change, not during the incident. If the rollback procedure cannot be written, the change is not understood well enough to be made — which is useful information and arrives cheaply at that point.
05 · Behaviour preserved, then improved
Including the behaviour that looks like a defect and turns out to be 2014 arriving at a workaround nobody wrote down. Those get listed and decided deliberately, not quietly dropped because they looked wrong.
06 · The deployment path, early
Reproducible build, migrations from empty, a container image, a runbook — often worth doing before the application changes at all, because without it every later wave is slower and riskier than it needs to be.
Adjacent questions
Three cases that look like this one and are not
You are leaving CUBA Platform
Then most of the system moves untouched and the cost sits in a small, identifiable part — a different conversation with a different shape — what moves, what gets rewritten, what has no replacement
The system should be retired, not moved
Sometimes the honest finding is that two of its four functions are done better elsewhere, the third is nobody's job any more, and the fourth is a spreadsheet. That is a cheaper answer than any migration and we would rather give it.
You want somebody to run it permanently
Modernisation ends; operations do not. We can hand over to your team or to another supplier, and we can put engineers inside your own team to carry it — the clauses that decide that arrangement
Questions
The ones that come before a budget exists
Our system works. Why would we touch it?
Usually you should not. A system that is old, dull and does its job is not a problem, and "it uses an unfashionable framework" is not a business case. The reasons to act are external and dated: the vendor has stopped issuing security updates, a platform you distribute through has changed its rules, a runtime you depend on reaches end of support, or the last person who understood it has handed in their notice. If none of those applies, we will tell you to leave it alone.
Rewrite or migrate?
Migrate, in almost every case we have seen, and the exceptions are rarer than enthusiasm suggests. A rewrite restarts from a specification nobody has written down, because the real specification is the behaviour of the system you are replacing — including the parts that look like bugs and are in fact 2014 arriving at a workaround nobody documented. Migration keeps that behaviour and replaces the parts that have actually failed.
Can you work on a system you did not build?
That is most of this work. It starts with a fortnight of reading rather than designing, and the first deliverable is a written account of what the system actually does — which is reliably not what the documentation says and often not what the business believes either. We have taken over a payment application in production, an inherited mobile codebase, and infrastructure somebody else had been running for years.
Will the system be down during the migration?
It should not be, and designing for that is most of the difficulty. Waves rather than a big bang, the old system running alongside the new one until the new one has earned the traffic rather than been handed it on a date, and a rollback procedure written before it is needed rather than during. On the payment application we maintain, the framework migration happened without taking the service down — people were paying with it throughout.
What does the assessment produce?
Two documents. A technical report with the methodology, the evidence, the root cause of what is actually failing, the associated defects, the security risks we noticed on the way past, a remediation plan — and a section on what the study could not establish and why. And an implementation instruction written for your engineers: step by step, per component, with a verification procedure, a rollback procedure, test scenarios and an acceptance checklist. You can hand both to another supplier.
Do you have to be the ones who do the work?
No, and we sign contracts that say so. There are engagements where we assess and your team implements, and that boundary is in the paper rather than in a conversation. An auditor who can only be paid if the audit finds work for him has an interest in what the audit finds, and that is worth removing from the arrangement rather than denying.
Next step
Bring the date, not the wish list
Which deadline is forcing this, what the system does today, and who is still there who remembers why. Three answers, and the assessment can be scoped from them.
Ask for an assessment
Two documents you could hand to a different supplier — including the finding that you should leave the system alone.
EvidenceA migration with the service still running
Replacing the foundation under a payment application while people were paying with it, then moving it again before the next deadline.