₦airaland Forum

There is a particular kind of silence that happens in a Nigerian office when someone asks, "So who wrote this system?"

Nobody knows. The developer left in 2018. There is no documentation. The server is a tower under someone's desk in Ikeja that nobody is allowed to touch. And every single month, the finance team still logs into it to close their books.

If that sounds familiar, you are dealing with legacy code. And at some point you will have to decide what to do about it.

I have watched this play out across schools, logistics firms, small banks and e-commerce shops, and the pattern is nearly always the same. The business does not fail because the old software stops working. It fails because the old software stops being changeable. A competitor ships a feature in two weeks. You quote three months, and you are not even confident about the three months.

This is a practical breakdown of what legacy code migration actually involves, what it costs, and how to avoid the mistake that swallows most modernisation budgets.

What is legacy code migration?

Legacy code migration is the process of moving an existing software application off outdated technology old languages, frameworks, databases or servers and onto a modern, supported stack, without losing the business logic that has been built into it over the years.

The important half of that sentence is the last part. Your old system is ugly, but it is also correct. Ten years of edge cases, tax rules, discount exceptions and "oh, we handle that customer differently" are buried in that code. A migration protects that knowledge. A careless rewrite throws it away and then spends eighteen months rediscovering it, one angry customer at a time.

Migration is not the same thing as a rewrite. That distinction is the whole ball game, and I will come back to it.

How do you know your system has become legacy?

It is rarely about age. A well-maintained ten-year-old Laravel app can be perfectly healthy. A two-year-old app with no tests and one developer who understands it is already legacy.

The honest signals are these:

• The framework or language version no longer receives security patches. PHP 5.6, Python 2, AngularJS 1.x, older Java and .NET Framework releases all fall here.

• Nobody on the team is willing to touch a particular file.

• Deployments happen at 2am on Saturdays because you expect something to break.

• You cannot hire for it. Ask around for a VB6 or Delphi developer in Lagos and see how that goes.

• Your hosting is a physical box, and your disaster recovery plan is hope.

• Small feature requests get quoted in months.

• There is no clean API, so every connection to a payment gateway or a partner is a hack.

That last one usually forces the decision here. A business limps along fine until it needs to plug into a payment provider, an identity check, a logistics API or a bank's reporting requirement. Suddenly the old system is not just slow, it is blocking revenue.

The four real options, and when each one is right

Every modernisation conversation collapses into four choices. Most vendors will push you toward the most expensive one. Here is the honest version.

1. Leave it alone. If the system is stable, rarely changes and is not exposed to the internet, the correct engineering decision is often to do nothing and spend the money elsewhere. Any consultant who never recommends this is selling, not advising.

2. Re-platform. Same code, new home. Move it from that tower under the desk to a managed cloud environment, upgrade the runtime, patch the security holes. Cheapest meaningful win, and it kills the "power surge took the server" category of risk entirely.

3. Refactor and re-architect. Keep the system, improve it from the inside. Tests around the parts that matter, dead code deleted, the monolith broken up only where there is a real reason to. This is where the durable value sits, and it is the least glamorous option, which is why it gets skipped.

4. Replace. Build new or buy off-the-shelf. Sometimes correct, especially when the old system encodes a business process you no longer run. But that should be the conclusion of an audit, not the opening assumption.

Most successful projects are a mix: re-platform first to stop the bleeding, then refactor the core, then replace the two or three modules that genuinely deserve it.

Why the big-bang rewrite keeps failing

Here is the pattern. A new CTO or a new vendor arrives, looks at the old codebase, and declares it unsalvageable. Budget is approved, a team goes away to build version 2.0, and meanwhile the old system must keep running, so it keeps receiving changes. Now you are paying for two systems.

Twelve months in, version 2.0 covers about 70% of what the old one does. The remaining 30% is the horrible stuff the exceptions, the reconciliation logic, the one report the regulator wants in a specific format. Nobody documented it and the people who understood it are gone. The project stalls, the budget is exhausted, and the old system is still in production, now even more neglected than before.

The alternative that actually works is incremental. It is sometimes called the strangler pattern: you put the new system in front of the old one, move functionality across a piece at a time, and let each piece prove itself in production before you move the next. The old system shrinks month by month until there is nothing left of it.

It is less exciting. It also finishes.

What does legacy code migration cost and how long does it take?

Nobody can quote you a real number without seeing the code, and anyone who does is guessing. But the shape is predictable.

A code audit someone reading your codebase properly and telling you what you actually have is typically two to four weeks and a small fraction of the total budget. Do not skip this. It is the single highest-return spend in the entire project, because it is what tells you whether you need option 2 or option 4.

A re-platform and version upgrade for a mid-sized application is usually measured in weeks to a few months.

A full incremental migration of a core business system runs six to eighteen months, delivered in slices, with working software in production throughout.

The number that matters more than any of these is what you are already spending. Add up your downtime, your emergency-fix weekends, the feature that would have won that contract, and the premium you pay a developer to work on technology nobody else wants to touch. That figure is usually larger than the migration, and it repeats every year.

Mistakes I would tell any Nigerian business to avoid

• Migrating without tests. If you have no automated tests, you have no way to prove the new system behaves like the old one. Write characterisation tests first tests that simply capture what the current system does, bugs included.

• Skipping the data. Data migration is routinely underestimated. Old databases are full of duplicates, inconsistent formats, and phone numbers stored six different ways. Budget real time for cleaning and reconciliation.

• No rollback plan. Every cut-over needs a tested way back. Not a theoretical one one you have actually rehearsed.

• Ignoring the people. Your staff have ten years of muscle memory in the old interface. Change everything at once and you will get quiet sabotage, not adoption.

• Choosing a stack for the CV, not the business. Microservices, Kubernetes and event streaming are wonderful. They are also mostly wrong for a company with four developers and 800 users.

Quick answers

Is legacy code migration the same as a rewrite?

No. A rewrite discards the old system and builds fresh. A migration preserves the existing business logic and moves it to modern technology, usually piece by piece.

How long does a legacy system migration take?

An audit takes two to four weeks. A re-platform takes weeks to months. A full incremental migration of a core system typically takes six to eighteen months, with usable software shipping throughout rather than only at the end.

Can a system be migrated without downtime?

In most cases yes. Running old and new side by side, routing traffic gradually and keeping a tested rollback path allows cut-over with minimal or zero downtime.

Which legacy technologies most commonly need migration?

COBOL, VB6, Delphi, PHP 5.x, AngularJS 1.x, jQuery-heavy front ends, older Java and .NET Framework applications, and on-premise databases without managed backups.

Should I migrate or just rebuild from scratch?

Rebuild only when the business process itself has changed. If the process is the same and only the technology is old, migrating is faster, cheaper and far less risky.

The bottom line

Old software is not a moral failure. It is evidence that something worked long enough to become important. The mistake is treating modernisation as one big heroic project instead of a series of small, boring, reversible steps.

Start with an audit. Find out what you actually have. Then take the cheapest step that removes the most risk, and repeat.

For anyone who wants a deeper technical breakdown of the audit-first, incremental approach including how re-platforming, refactoring and data migration are sequenced on real projects this walkthrough of legacy code migration covers the process end to end.

Happy to answer questions in the thread if anyone is stuck on an old system right now. What are you all still running that you wish you weren't?