Legacy modernization and system takeover

For software that still runs the business and that nobody currently owns.

What this is

Legacy system modernization is what happens when software that works is also software nobody can safely change. We take over systems built by people who have left, document what is actually there, stabilise it, and then modernise it in stages while it keeps running. Assessment comes first, always. Rewriting before understanding is how companies end up with two systems instead of none.

What the engagement covers

  • Takeover: documentation, environment reconstruction, and getting a build running again.
  • Stabilisation: the failures that wake people up, fixed before anything is modernised.
  • Dependency and platform upgrades, staged rather than all at once.
  • Strangler pattern migration, so the business keeps running throughout.
  • Test coverage built around the riskiest logic first.
  • Handover to your team, or ongoing ownership by ours.

Who this is for

Companies whose core system was built by a developer who is gone. Businesses running software on versions that no longer receive security updates. Anyone who has been quoted a full rewrite and suspects there is a cheaper answer. There usually is.

Rewrite is almost never the right first move

It is the most commonly proposed answer and the most commonly regretted one.

A rewrite means running two systems in parallel, reproducing years of undocumented business rules from memory, and delivering no new value until the day you switch. Most rewrites we are called in to rescue were approved because the existing system was hard to read, which is a fixable condition rather than a terminal one.

  • Take over and document first, because you cannot replace what nobody can describe.
  • Stabilise the failures that cost real money, which usually buys a year of breathing room.
  • Upgrade in stages, each one shippable and reversible on its own.
  • Replace piece by piece behind the existing interface, so the business never waits for a switch date.

What takeover actually involves

The first job is usually reconstruction rather than engineering, and it is worth knowing that before the budget is set.

A system whose authors are gone often cannot even be built from scratch on a new machine. Environments were configured by hand, credentials live in someone's personal account, and the deploy process exists as a sequence of steps a person remembered. Before anything improves, that has to become reproducible.

We treat that as the first deliverable, not as overhead. At the end of it you have a system your own team could take back, which is a real improvement even if you change nothing else.

When to leave it alone, and what it costs

Not every old system needs attention. Boring, cheap and stable is a perfectly good state.

Modernise the parts that hurt, which usually means the parts that block a business change or carry security exposure. Let the quiet parts stay quiet.

  • Assessment first, €4,500 to €6,500 for five days, so the plan is based on the system rather than on assumptions.
  • The assessment fee comes off the first invoice on projects above €50,000, valid six months.
  • Takeover and stabilisation is scoped from the assessment, because guessing at it would be dishonest.
  • If the honest answer is that the system should be left alone for another two years, the report will say that.

Questions we get asked

Can you take over a system built by someone else?

Yes, that is most of this work. We have taken over systems with no documentation, no reproducible build and no original author available. The first phase is reconstruction and documentation, and it is scoped explicitly rather than hidden in a development estimate.

Should we modernise or rewrite?

Modernise first in almost every case. A rewrite means two systems in parallel and no new value until switchover. We will tell you when a rewrite genuinely is the cheaper path, and it does happen, but it is rarer than vendors suggest.

What about very old technology?

We work with what is there. Our team has shipped C++ and x86 assembly middleware for physical hardware, and migrated a live production iOS app from Objective-C to Swift without interrupting users. Old is not the same as impossible.

How long does a takeover take?

Reconstruction and documentation typically run four to eight weeks depending on how much was undocumented. Stabilisation follows, and modernisation is staged after that. The assessment gives you the actual number for your system.

Will the business keep running during this?

That is the constraint we design around. Staged migration behind the existing interface means there is no switchover day and no window where the business waits for us.

Further reading

Consulting

Start with the assessment, not the contract

Tell us what is worrying you. We reply within one working day, and you get a written read on your situation within three. Free, and there is no sales sequence behind it.