Modernization
Cost & Budgeting5 min read
How much does legacy system modernization cost? Ranges by approach, hidden costs, and the cost of waiting
Rehost, refactor, or rebuild: each has a different price and a different risk. Here are planning ranges, the line items that get missed, and how to put a number on doing nothing.
Working on something like this?
Get an estimateThe short version
- Cost depends mostly on approach. Rehosting is the cheapest, a full rebuild the most expensive, and incremental refactoring sits between with the lowest risk of a write-off.
- The application is rarely the biggest line. Data migration, parallel running, and missing documentation usually are.
- Most budgets fail on what is not yet known about the system. A short assessment is the cheapest way to move the estimate from a guess to a range.
- Doing nothing has a price. Price it before you compare options, or the cheapest option will always be to wait.
Anyone asking what modernizing a legacy system costs is usually holding two numbers they do not trust: a vendor's estimate and a rough sense of what the current system costs to keep alive. This article is for comparing the two honestly.
The numbers below are planning ranges, not a quote. They assume North American delivery and one business application of moderate complexity. A portfolio of many applications is a different exercise, and the first step in it is deciding which ones deserve money at all, which we cover in modernizing without a big-bang cutover.
Cost ranges by modernization approach
Cheaper is not better. Rehosting an application that nobody can safely change gets you a hosting bill and the same constraints. Rebuilding an application whose behaviour nobody has written down means paying to rediscover its business rules by getting them wrong. The right approach is the one that matches what is actually wrong, and that is why assessment comes first.
The costs that do not appear in the headline number
1
Data migration
Fifteen years of data holds duplicates, orphaned records, and fields repurposed for something their name never suggested. Cleaning, mapping, and reconciling it is frequently larger than the application work, and it cannot be estimated without looking at the data itself.
2
Running both systems at once
A safe cutover means the old system stays live while the new one proves itself. That is a real cost: two environments, two sets of support, and sometimes two sets of licences, for as long as the overlap lasts.
3
Missing documentation and tests
When the original developers are gone, behaviour has to be recovered by reading code and watching production. Characterisation tests, written to pin down what the system does today, are what let anyone change it with confidence. They cost real time and are worth it.
4
Integrations nobody listed
Every legacy system has consumers that were never documented: a nightly export, a spreadsheet macro, another team's report. Finding them during the project is expensive. Finding them after cutover is worse.
5
Compliance and security work
Moving an auditable system means evidencing the controls again, and modernising is usually the right moment to close long-standing gaps. Plan for SOC 2 or HIPAA evidence if either applies, and expect it to be cheaper designed in than retrofitted.
6
People and training
Users change how they work, support learns a new stack, and your team inherits something unfamiliar. Training and handover sit outside most engineering estimates, but they decide whether the new system gets adopted.
What drives the range within each approach
- Size and complexity of the codebase. More modules, more business rules, more edge cases.
- Number of integrations. Each connected system adds testing and a cutover dependency.
- Data volume and quality. Both the size of the migration and how much needs correcting.
- Technology age. Mainframe and unsupported runtimes mean scarcer skills and fewer tools.
- Uptime requirements. Zero-downtime cutover costs more than a weekend window.
- How many people must agree. Idle engineering days waiting on a decision are still billed.
How to put a number on doing nothing
The cheapest line on any comparison is always “leave it alone”, because its cost is spread across budgets nobody adds up. Add it up before you decide.
Put that total against the modernization cost over the same three to five years. The comparison is not always in favour of modernizing, and when it is not, you have a defensible reason to leave the system alone. When it is, you have the business case written.
How to keep the estimate from doubling
1
Pay for an assessment first
A short engagement to read the code, profile the data, and map the integrations turns a guess into a range and tells you which approach fits. It costs a small fraction of the build and removes the largest source of overruns.
2
Modernize in slices, with a value date for each
Moving one seam at a time means money is spent against something shipped, and you can stop when the remaining system no longer justifies the cost. A budget approved as a single block cannot be stopped without being wasted.
3
Agree the parallel-run period early
Decide how long both systems live and what the criteria are for switching one off. Leaving it open is how a six-month overlap becomes two years.
4
Hold contingency for discovery, openly
Any honest estimate of a system you cannot fully see carries contingency. Showing it as a line is better than burying it in rates, and it makes the conversation about what is still unknown.
For how the infrastructure side prices out, see cloud migration cost drivers. To see the approach applied, read how a legacy enterprise system was modernized on Azure. If you want a number for your own system, our software engineering team can scope an assessment, and you can reach us here.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Per application, rehosting typically costs $30,000–$120,000, replatforming $60,000–$250,000, incremental refactoring $150,000–$600,000, and a full rebuild $300,000 to over $1,000,000. Data migration, parallel running, and undocumented behaviour usually move the total more than the application itself.
Rehosting, moving the application to cloud infrastructure with little change, is the cheapest and fastest. It does not make the application easier to change, so it suits systems that are stable and need a new home rather than new capability.
Refactoring in slices usually costs less in total and carries far less risk, because value ships early and the old system keeps running. A full rebuild can make sense when the existing design cannot be salvaged, but it concentrates the cost and the risk into one cutover.
A rehost takes one to three months, a replatform two to five, incremental refactoring six to eighteen, and a rebuild nine to twenty-four. Elapsed time depends heavily on data migration, the number of integrations, and how quickly decisions are made.
Add up the annual cost of staying, which is maintenance effort, delayed change, specialist premiums, incidents, and licence or security exposure, and compare it with the modernization cost over three to five years. Include only savings you can measure, and leave speculative revenue uplift out of the case.
The usual causes are data that was worse than assumed, integrations nobody had documented, missing tests that made changes risky, a parallel-run period that grew, and scope agreed before the system was properly assessed. A short up-front assessment addresses most of them.
If the system supports a common function and a packaged product fits, replacing it is often cheaper. If it encodes processes that differentiate your business or integrates deeply with your own data, modernizing is the better route. Our build versus buy framework covers the decision.