How should a European company outsource legacy modernisation?
Outsource legacy modernisation in vertical slices behind a strangler pattern, keeping domain knowledge and architectural authority in-house, and never as a single big-bang rewrite handed to an external team. That one sentence contains the whole difference between modernisation programmes that finish and modernisation programmes that become a second legacy system running alongside the first.
European companies face this problem more than most. A great deal of the continent's industrial, insurance, logistics and public-sector software was written between fifteen and thirty years ago, works, and is maintained by people approaching retirement. The pressure to modernise is rarely about elegance. It is that the system blocks something concrete — a compliance obligation, a cloud migration, an integration a customer demands, or simply the ability to hire anyone willing to maintain it.
Which modernisation strategy fits, and can it be outsourced?
| Strategy | What it means | Risk | Outsources well? |
|---|---|---|---|
| Rehost | Move the workload to cloud infrastructure largely unchanged | Low | Yes — well-defined, measurable, and a common first step |
| Replatform | Modest changes — managed database, container runtime, updated runtime version | Low to moderate | Yes, with clear acceptance tests |
| Refactor | Restructure the code, extract modules, keep behaviour | Moderate | Yes, in slices, provided characterisation tests exist |
| Rearchitect (strangler) | Route traffic progressively from old to new capability by capability | Moderate, and controllable | Best fit for an external team — each slice is independently valuable |
| Rewrite | Rebuild the system, then switch over | Highest | Rarely — the failure mode is a two-year programme with no intermediate value |
| Replace | Adopt a commercial product and migrate data | Varies | Partly — data migration and integration outsource well; process change does not |
The strangler pattern is the default recommendation for outsourced work for one structural reason: it produces value every few weeks, which means you find out whether the arrangement works while you can still change it. A rewrite tells you nothing until the end, which is exactly the wrong risk profile for a relationship you have not tested. If cloud migration is part of the picture, our on-premise to AWS migration strategy covers the infrastructure half of the sequence.
How do you hand over a system nobody documented?
This is the hardest part, and it is not a documentation problem — it is an archaeology problem. The knowledge exists in three places: the code, the production behaviour, and a small number of people's heads. Plan to extract from all three.
Start with observed behaviour rather than intent. Instrument the running system to record which endpoints, batch jobs and code paths are actually used, and over what volumes. In most decade-old systems a substantial share of the surface area is dead or near-dead, and discovering that before you pay someone to migrate it is the single highest-return activity in the programme.
Then write characterisation tests: tests that capture what the system currently does, including the behaviour everyone considers a bug. These become the acceptance criteria for every slice, and they are what makes an external team's work verifiable without deep domain knowledge. Producing them is often the right first paid deliverable for the vendor, because it forces genuine engagement with the code.
Finally, ring-fence your internal experts' time deliberately — a scheduled few hours a week, not ad-hoc interruption. The most common cause of modernisation drift is the one person who understands the billing logic being too busy to answer questions for a fortnight.
How should the contract be shaped?
Split discovery from delivery. Fixed-price discovery of four to six weeks producing a dependency map, a usage analysis, a slice sequence and a defensible estimate is a reasonable thing to buy, and its output is valuable even if you then change vendor. Fixed-pricing the delivery of an undocumented system before that discovery is how both sides end up in a change-request argument.
For delivery, capped time-and-materials per slice tends to work best: the vendor carries the estimating discipline, you keep the ability to stop after any slice, and neither side is betting on an estimate made in ignorance. Our overview of software outsourcing pricing models in Europe compares the alternatives in more detail.
Three clauses deserve particular attention in modernisation work. Source code and infrastructure definitions live in your repositories and your cloud accounts from day one. Documentation and characterisation tests are named deliverables, not goodwill. And there is a defined transition period with a knowledge handover obligation — the scenario in our guide to switching outsourcing vendors is far more painful mid-modernisation than mid-feature-work.
Where does AI genuinely help — and where does it mislead?
AI assistance has changed the economics of modernisation more than any tooling shift in the last decade, but unevenly. It is genuinely strong at explaining unfamiliar code, generating characterisation tests against observed behaviour, drafting documentation for undocumented modules, and mapping dependencies across a large codebase. Those are the expensive, tedious parts of discovery, and compressing them is real value.
It is much weaker at the thing vendors most like to promise: automated translation of a legacy codebase into a modern language. Translated output typically compiles and often runs, while quietly reproducing the original's structure — you end up with the same tangled design expressed in newer syntax, plus a subtle behavioural difference nobody catches until quarter-end. Where the legacy system encodes business rules accumulated over decades, those rules are exactly what a translator cannot validate.
Use AI to understand and to test, be sceptical of using it to transform wholesale, and review its output against characterisation tests rather than against a diff. If AI-assisted delivery forms part of your vendor's pitch, our guidance on reviewing AI-generated code from outsourcing vendors sets out the review posture that keeps the speed without the surprises.
What does a realistic first year look like?
- Weeks 1–6: discovery. Usage instrumentation, dependency mapping, dead-code identification, slice sequencing and a costed plan.
- Weeks 4–10: safety net. Characterisation tests around the first slices, plus the observability to detect behavioural drift in production.
- Weeks 8–20: first slice in production. One genuinely valuable capability routed through the new path, with a working rollback.
- Months 5–12: cadence. Successive slices, with the routing layer carrying more traffic each quarter and the legacy surface measurably shrinking.
Measure progress by traffic moved and legacy surface retired, not by lines of code written. If no slice reaches production in the first five months, the programme has already drifted toward a rewrite, whatever the plan says. ILMTEC's AI and product engineering teams work this way by default, in slices with production checkpoints.
Who owns the programme internally?
Every modernisation that finishes has a named internal owner with the authority to say no. Not a steering committee, and not the vendor's delivery manager — one person who decides slice sequencing, arbitrates when a discovered behaviour turns out to be load-bearing, and holds the line when a business unit asks for new features to be built into the system being retired.
That last responsibility is the one most often underestimated. Modernisation competes for the same engineering capacity as the roadmap, and without a clear owner the slices quietly stop while feature work continues on the legacy platform, which makes the eventual migration larger. Give the owner a visible measure — traffic moved off the legacy path per quarter — and report it to the same forum that reviews the roadmap.
Why these programmes fail
Modernisation programmes fail for reasons that have almost nothing to do with technology. They are scoped as rewrites because that is easier to plan than a sequence. They migrate dead functionality because nobody measured what was used. They lose their internal expert to another priority. They accept a fixed price for work nobody has yet understood. And they measure activity rather than traffic moved, so everyone can report progress for a year while the legacy system continues to run everything that matters.
