Skip to content

Legacy modernization: your aging systems replaced in waves, while the business runs.

For companies in Europe, and US or UK companies with systems there, stuck with an ERP that talks to nothing or a platform nobody patches anymore. Bounded scope, fixed fee, a rollback before every wave.

Tell us about your projectA 20-minute video callHow a modernization runs

What are legacy modernization services?

Replacing or rebuilding systems that the business still depends on, without stopping the business: mapping what each one really does, sequencing the move in waves, and handing back a platform your own team can run.

A system ages along three axes at once: its technical foundation drifts toward obsolescence, its workarounds quietly become the rule, and its running cost climbs without anyone measuring it. The cost of acting is visible on a quote. The cost of waiting is not, which is precisely why companies wait too long.

When the real question is whether to move at all, price the exit first. The method is in our article on modernizing or renegotiating, and the board-level case in making the case for technical debt.

When the system holds personal data about people in Europe, the move is also the moment to decide where that data will run and under which contracts. That choice is written down before the target is picked, and the new accounts are opened in your name.

Developers working at their desks in an open-plan office (illustration photo)

Your team has the skill. What it lacks is having seen one fail.

Internal teams facing their first large migration are rarely short of skill. They are short of the knowledge that only comes from having run one. That knowledge is what shortens the project, and it is the whole reason to bring someone in for a bounded period rather than permanently.

  • Which edge cases surface at cutoverAnd which ones can be flushed out weeks earlier, on a test wave.
  • How long a data cleanup really takesUsually longer than the build, and planned as such from the start.
  • What a usable rollback needsRehearsed, timed and signed off, not a paragraph in the plan.

Four stages, in this order: what you hold at the end of each.

The order matters more than the tooling. Most failed migrations chose the target before mapping the workloads, and discovered mid-project that the target did not fit.

  1. Before any target

    A map of what each system does for the business.

    Criticality, dependencies, what is dead code. On half the engagements we see, no current map exists, and producing one changes the conversation.

  2. Wave by wave

    Closed scopes that ship and are used on their own.

    Each wave has a measurable objective and an explicit dependency on the previous one. The first is the one that pays back fastest, not the most interesting.

  3. Before the code

    A rollback plan, signed off.

    How we return to the previous state, how long it takes, what data would be lost. It turns a go-live into a decision rather than a gamble.

  4. At handover

    Backups that restore, and runbooks your team wrote with us.

    A restore tested on the new platform, monitoring that sees the new machines, procedures rewritten.

    Why backups that run are not backups that restore

Everything at once, in waves, or not yet: which one your situation calls for.

Three ways to handle a legacy system, what each one risks, and when it is the right call
Three ways to handle a legacy system, what each one risks, and when it is the right callWhat it risksWhen it is the right call
Rebuild everything at onceThe biggest and most expensive failures: one cutover, no way backRarely. A large organization with deep resources and nothing else running on the system
Modernize in wavesTwo platforms to run for a while, which has to be planned and staffedMost mid-sized estates: each wave ships, pays back and de-risks the next
Wait and renegotiateThe cost of waiting keeps accruing, out of sightNo legitimate trigger yet, or a vendor that moves once it sees a costed alternative

10+business applications rebuilt, wave by wave

CFAO case study, measured figure

CFAO, international distribution group

Over ten applications rebuilt, one wave at a time.

The problem
A corporate IT department running business applications, across subsidiaries in several countries, on operating systems and middleware that had reached end of support.
What was delivered
Servers brought back to a supported baseline, then applications migrated one at a time onto unified cloud hosting. Consistency preserved across the group, and the hosting risk moved to the provider.
Read the case studies

Three things we refuse, said before you sign.

Measured in July 2026, across every engagement delivered since 2019: no client has had to call us back on an emergency after handover. The few follow-on contracts extended a warranty or widened the knowledge transfer, never to repair something we had left behind. That record is the direct consequence of these three refusals.

  • Starting without an internal owner.Someone on your side is named and freed from other duties for the duration. If nobody can be, the project is not ready.
  • Rebuilding everything at once.In a mid-sized company it is the method that produces the biggest failures. Waves, or nothing.
  • Leaving knowledge in our heads.Documentation written as we go, a decision log, credentials transferred, one person trained.

Who runs your migration, and who takes it over.

The engineers who scope the waves are the ones who run them. On critical migrations, Laurent and Clairmont work as a pair, and one person on your side is trained along the way rather than in the last week.

  • Laurent Tulpan, founder of Coeur du WebLaurent, founder and CTOScopes the program, sequences the waves and defends the trade-offs to your leadership.
  • Clairmont, technical leadClairmont, technical leadArchitecture, infrastructure and integrations: the rollback plans and the restore tests.

What you sign for a legacy modernization, in short.

Price
Fixed before work starts, per wave or for the program. An estimate that turns out wrong is our problem, not a change order.
Scope
Closed at scoping. A change is costed and decided, it does not drift in silence.
Data
No data loss, in writing. A loss attributable to our work is restored at our expense.
Rollback
Written and signed off before each wave, tested before go-live.
Exit
Documentation, credentials and a trained person on your side. You run it, or hand it to anyone.
How we work: every commitment, with its limit

Triggers, failure modes, your data: before you commit.

How do we know when modernization is genuinely overdue?

Look for a trigger rather than a feeling. Three are legitimate:

  • the platform has reached end of life, so security patches have stopped
  • a business need cannot be met because the system has no way to integrate
  • a platform change elsewhere forces your hand

If the only driver is a diffuse frustration in the leadership team, the project has no compass yet and it is better to wait.

Why do these projects fail so often?

Usually for one of three reasons, and none of them is technical difficulty:

  • Everything is attempted at once.
  • Nobody internal owns the project, so no one can settle a contradiction between two departments.
  • The rollback plan was never written, which turns the first bad hour of the cutover into a crisis instead of a decision.
Can this run alongside our normal operations?

Only if someone is genuinely freed up for it.

Handed to a team already carrying the daily load, a migration stretches, and a stretched infrastructure project ends up in the worst state: half the estate migrated, two platforms to monitor, two sets of procedures.

If the internal bandwidth is not there, the work should go to someone whose only job is this, on a bounded scope.

How long does a modernization take?

It is counted in waves, not in one date. Each wave has a closed scope that ships and is used on its own, and the first one is chosen because it pays back fastest.

The total depends on the inventory, which is why the duration is fixed at scoping, in writing, rather than promised before anyone has mapped the workloads.

What guarantees do we get on the data?

A written commitment on no data loss, in the contract rather than in the pitch. If a migration causes a loss attributable to our work, restoring it is on us.

Alongside that, acceptance criteria are written before the build, the rollback is signed off before construction, and a restore is tested on the new platform before anyone calls the project finished.

And when the modernization needs a new tool built?

Build and automate

Software, automations and AI hosted in the EU, sources in your name.

Closer to your case

All services

Describe the system and the deadline. You will know whether it is time.

20 minutes to tell whether this is a modernization, a migration, or a project that should wait. If waiting is the right answer, we will say so.

Tell us about your project

A 20-minute video call