Somebody says the system is old and needs replacing. Everybody nods, because it is old and it is annoying, and replacement sounds like progress.
Six months later there are two systems running in parallel, the new one does about seventy per cent of what the old one did, and nobody can switch the old one off because of a report that finance needs every quarter that nobody knew existed.
This is the most expensive avoidable mistake in business software, and it starts with a decision made on a feeling rather than a test.
Age is not the signal
The US Government Accountability Office periodically reviews the federal government's most critical legacy systems. In its most recent assessment, those systems ranged from about twenty-three to sixty years old [1]. Some were still doing their job.
What made them genuine problems was specific and checkable: hardware no longer supported by its manufacturers, known cybersecurity vulnerabilities in seven of the eleven, and most of them written in older languages with, as GAO puts it, a dwindling number of people available with the skills needed to support them [1].
None of those findings is "it is old". Each is a concrete condition you can check on your own system this week.
So the useful questions are these. Do small changes still take a predictable amount of time? Can anybody safely change it? Does it still meet your compliance obligations? Are the things underneath it still supported by the people who make them? A system can be fifteen years old and entirely fine, or three years old and genuinely finished.
The test that settles most of it
Ask for one small, low-risk change and time it honestly.
If a minor change takes hours and behaves as expected, the system is maintainable, whatever it looks like inside. If it takes days, arrives with heavy caveats, or breaks something unrelated, that is a concrete measurement of the thing that actually costs you money.
Run that test before you commission any opinion about the code, including ours. It measures the property that matters rather than the aesthetics of the source.
The second test is a list: every piece of software your system depends on, with the date its support ends. Frameworks, databases, operating systems, paid libraries, hosting. Once something underneath you stops receiving security fixes, the timeline stops being yours and becomes somebody else's support policy.
Those two exercises take a few days between them and answer most of the question. Nearly everything else in this decision is opinion until you have them.
Four options, not two
The conversation is usually framed as fix it or replace it. There are four, and the middle two get skipped.
Maintain it properly. Bring dependencies up to date, apply security patches, fix the defects everybody has learned to work around, and write down how it works. A surprising number of systems described as needing replacement have simply never been maintained. A few months of proper care sometimes changes the assessment entirely, at a small fraction of the cost of the alternative.
Fix specific parts. Rewrite the one module that causes most of the trouble and leave the rest alone. Most of the pain in an old system is concentrated rather than evenly spread, and finding out where it is concentrated is cheap.
Replace it piece by piece. Route individual functions to new code behind the existing interface, until the old system has nothing left to do. Slower than a rebuild and considerably lower risk, because at every point you have a working system and the option to stop. It suits businesses that cannot afford a big-bang cutover, which is most of them.
Rebuild it wholesale. Sometimes correct, and the case for it should be specific.
A full rebuild is genuinely right when the platform underneath is unsupported and cannot be upgraded, when the business model the system encodes has fundamentally changed rather than merely evolved, when nobody can be found who can work on it at any price, or when a compliance obligation cannot be met within the existing structure. Wanting it to look modern is not on that list.
Why rebuilds cost more than the estimate
Three reasons, and they compound.
The first is that a rebuild has to reproduce behaviour nobody has written down. Years of small fixes, exceptions and edge cases live in that code, some of which started as bugs and quietly became features that the business now depends on. Rediscovering all of them is the actual work, and it is almost never in the estimate, because at estimating time nobody knows what is in there.
The second is the parallel period. You run both systems at once, keep data consistent across them, train people twice, and apply every fix in two places. This is where rebuild budgets actually go. It gets scoped as a few weeks and turns out to be several quarters.
The third is that the original build had an advantage the rebuild does not: it did not have to match anything. That is why a rebuild frequently takes longer than the system it replaces took to write in the first place, which people find counterintuitive right up until they are in one.
There is also a discipline point. Do not rebuild and add new features simultaneously. Changing what the system does while changing how it is built removes your ability to tell whether something is broken or merely different. Reproduce the existing behaviour, prove it, then change it.
Ask what will be different this time
A rebuild only resets the clock if the practices that caused the decay have changed.
If it is delivered under the same deadline pressure, with no standing maintenance budget, by a team who will accept whatever is asked for without pushing back, it arrives in the same condition in a similar number of years. The code will be newer. Nothing else will be.
So ask directly what will be different. Vague answers are a prediction. Concrete ones sound like: maintenance is now a standing budget line, dependencies get updated quarterly rather than in panic batches, and somebody owns the decision about what does not get built. Our guide on saying no to a feature covers that last one, which is the mechanism that most reliably turns a new system into an old one.
The plan, and the part everyone forgets
GAO's minimum bar for a federal modernisation plan is a reasonable one to borrow: milestones, a description of the work, and details regarding the disposition of the legacy system [1]. When it assessed eleven critical systems, only three had plans containing all three elements [1].
The third is the one that gets left out, and leaving it out is how you end up running both systems forever. Without a written decision, somebody keeps the old one alive just in case, its licences keep renewing, and its data keeps drifting from the new system's until reconciling them becomes its own project.
Write down when it gets switched off, who confirms it is safe to do so, what happens to its data, and who is accountable for that happening. That turns a hope into a task with an owner.
Watch the ratio, not the incident
Old systems rarely fail dramatically. They consume.
GAO reports that federal agencies typically spend about eighty per cent of their IT budget operating and maintaining what already exists, rather than building anything new [1]. That is a US federal figure and your business is not a federal agency, but the ratio is the thing worth tracking in your own numbers. It tells you how much capacity you have left for anything at all, and it moves slowly enough that nobody notices until there is none.
If most of your technology budget is going on keeping things alive, the problem is not any individual system. It is that nothing has been retired and nothing has been maintained.
What it looks like when you get it right
The businesses that come out of this well have one thing in common: they made the decision reversible.
They did not commit a year's budget to a plan drawn up before anybody opened the system. They spent a small amount finding out what was actually true, fixed the things that were genuinely urgent, and then took the single worst part and replaced it as a contained piece of work with a real deadline and a real number attached.
At the end of that they knew three things they could not have known at the start: what the code is actually like to work in, whether the supplier's estimates hold up under contact with it, and whether the remaining problems are concentrated or spread throughout. Any one of those changes the decision. Together they usually settle it.
The businesses that come out badly did the opposite. They decided first, on a feeling, and discovered the facts afterwards at full price.
The data is the hard part
Whatever you decide, the data outlives the system, and it is routinely treated as a footnote in the plan when it deserves to be a phase of its own.
Old systems accumulate data that does not fit the rules the new system will enforce. Records with missing fields that were optional in 2018 and are mandatory now. Duplicate customers created before anybody added a check. Dates stored as text. Statuses that were removed from the interface years ago but still sit on ten thousand historical rows. Every one of those has to be decided on individually: migrate it, correct it, or leave it behind.
That decision is a business decision rather than a technical one, and it needs somebody from the business to make it. A developer cannot tell you whether a customer record with no trade licence number should be migrated, rejected, or flagged for review. Left to a technical team under deadline pressure, these get resolved by whatever is quickest, and the consequences surface months later when somebody cannot find a historical order.
Two practical rules. First, profile the data before committing to a plan: how many records, how many fail the new rules, how many are duplicates. That count is usually shocking and always changes the estimate. Second, decide what you are not migrating, explicitly. Keeping ten years of history because nobody wanted to make a decision is how a six-week migration becomes a six-month one.
If the answer turns out to be that some history must stay accessible but does not need to be live, that is a separate and much cheaper problem: a read-only archive rather than a migration.
A staged plan that works
For most businesses the honest sequence is not a decision followed by a project. It is a sequence of small commitments, each of which produces a real measurement for the next.
Fix what is urgent, meaning anything unsupported or carrying a known vulnerability. Document what exists, which pays for itself whichever way you eventually go. Replace the single worst part, and see what that actually cost against what was estimated. Then decide about the rest, with a real number instead of a guess.
Each stage leaves you with something usable and the option to stop. That is the opposite of how these projects normally run, where the whole budget is committed to a plan written before anybody knew what was inside the system.
Getting a straight answer
Both available opinions are biased. The people who built the system know where the problems are, and are either attached to it or embarrassed by it. A new supplier is looking at code they did not write, which reliably looks worse than code they did, because you see the decisions without the constraints that produced them. Nearly every odd-looking thing in an old system is the residue of a real problem: a deadline, a client demand, a limitation of a tool that no longer exists.
A supplier proposing a rebuild after an afternoon of reading is telling you about their own comfort, not about your system.
Five questions cut through it. What in the current system cannot be fixed, and why? What would happen if we maintained it properly for six months instead? Which parts could be replaced individually? How would you prove the new system behaves identically? And how long do we run both? A supplier with answers to all five has looked at your system rather than pattern-matched it.
Two things worth knowing
If the system works but nobody understands it, that is a knowledge problem rather than a software problem, and rebuilding is an expensive way to solve it. Paying somebody to read it and document how it works costs a fraction of replacing it, and if the conclusion is still that it has to go, you now own the specification for its replacement. That work pays for itself either way, which makes it unusual.
And moving the same system to the cloud changes where it runs, not how maintainable it is. That can be worth doing for cost, resilience or support reasons. It should be described accurately rather than sold as modernisation, and our cloud migration guide covers what the move does and does not achieve on its own.
This article is about operational systems. A website is a different decision, because its value sits largely in content, search position and appearance, so replacing the underlying build is comparatively low risk when redirects are handled properly. Our website redesign guide covers that case.
What it costs to find out
A codebase and dependency review starts from around AED 4,000 with us. That covers what the system is built on, what is no longer supported, where the genuine risks sit, and a plain recommendation between the four options. Final pricing depends on scope, and these are our own figures rather than a market survey, since no official body publishes rates for this work.
Ask anybody offering that work, including us, whether the assessment can conclude that the system is fine and should simply be maintained. If a supplier cannot describe the circumstances in which they would recommend keeping it, the conclusion was decided before the work began.
Before spending anything: request one small change and time it, and list every dependency with its support end date. A few days, no cost, and you will know more than the meeting did.
References
- US Government Accountability Office, Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795)
- ISO/IEC 25010:2023, systems and software quality models
- ISO/IEC/IEEE 14764:2022, software life cycle processes, maintenance
- SKIMBOX, mobile app maintenance cost in Dubai
- SKIMBOX, saying no to a feature
- SKIMBOX, website redesign in Dubai
- SKIMBOX, cloud migration to AWS in the UAE
The GAO report cited above concerns US federal government systems. It is referenced for the underlying failure modes and planning standard, which apply broadly, rather than as guidance addressed to private businesses in the UAE.
