"It depends" is the honest answer to what legacy modernisation costs, but it isn't a useful one. You need a number to take to a budget meeting, and you need to know whether the quotes you receive are reasonable.
This article gives you a method for producing that number yourself. It won't be as precise as an estimate made after a proper discovery phase, but it will be within the right range, and it will tell you where the uncertainty is. The method comes down to four steps: take an inventory of what the system does, size each part, add the work that isn't building, and apply an uncertainty range.
Step 1: Take an inventory of what the system does
Cost follows the amount of work, and the amount of work follows what the system actually does. Before any sizing, list:
- Workflows and screens. Every distinct thing a user does: create an order, approve a request, update stock. Mark each as simple (a form and a list, little logic) or complex (approvals, calculations, status changes, rules that differ by site or customer).
- Reports and exports. Every report, printout, and spreadsheet export people rely on, including the ones that only run at month-end.
- Integrations. Every other system it exchanges data with, and how: a documented API, a file drop, or someone re-keying data by hand.
- Data. Roughly how many tables or record types, how many years of history, and how many side spreadsheets hold data that should be in the system.
- Users and roles. How many kinds of user see different things or have different permissions.
Include the workarounds. If the team keeps a spreadsheet next to the system because the system can't do something, that spreadsheet is part of the scope. It's often the part that matters most.
Step 2: Size each part
With the inventory in hand, apply rules of thumb to each item. These are the ranges we use as a first pass, in person-days of development effort:
| Item | Typical effort |
|---|---|
| Simple workflow or screen | 2–4 days |
| Complex workflow | 1–3 weeks |
| Report or export | 1–3 days |
| Integration with a documented, stable API | 2–5 days |
| Integration with a system that has no API | 2–3 weeks |
| Data migration, significant history | 20–40% of build |
Two items deserve more attention than the rest.
Integrations are the widest variable
An integration that sounds simple often isn't, because it depends on the other system's API quality, rate limits, data format, and update frequency. The gap between "it has a good API" and "it has no API and we'll need a custom connector" is the difference between days and weeks. If you're unsure which you have, assume the slower one.
Data migration is the most underestimated
Moving data sounds like a technical task, but it almost always involves quality problems that have built up over years: fields used inconsistently, records entered in several places and never reconciled, a schema that made sense in 2005 and doesn't map cleanly to what's needed now. On projects with significant historical data, migration typically adds 20–40% on top of the build effort. Use the high end if your team relies on side spreadsheets, because those have to be reconciled too.
The upside is that migration forces a data clean-up that pays off afterwards: one source of truth, cleaner data for reporting, and an end to the fragmentation that erodes management's confidence in the numbers.
Step 3: Add the work that isn't building
This is where most self-made estimates and cheap quotes fall short. Building the features is only part of the project. On top of the build and migration figure, add:
- Discovery and design: about 15%. Understanding how the current system really behaves, which is rarely how it's documented, and designing the replacement.
- Testing and quality assurance: about 20%. More if the system handles money, compliance, or safety-critical data.
- Rollout, training, and stabilisation: about 10%. Moving users across in phases, running both systems briefly, and fixing what real usage turns up.
Together these add roughly 45% to the build figure. If a quote is well below your estimate, one of these is usually missing.
Step 4: Apply an uncertainty range
Legacy systems hide things. Business rules buried in code nobody has read in a decade, reports that turn out to feed a regulator, data that means something different at each site. Multiply your total by an uncertainty factor that reflects how well the current system is understood:
- ×1.2 if the system is documented and someone who knows it well is available throughout the project.
- ×1.3–1.4 if documentation is thin but the people who use it daily can explain it.
- ×1.5 if the original developer is gone, there's no documentation, and the code is the only record of how things work.
Present the result as a range, from the unadjusted total to the adjusted one. A range is more honest than a single figure, and it tells your budget holder how much contingency to hold.
A worked example
Take a mid-sized operations system used across two sites: eight simple workflows, four complex ones, six reports, a documented integration with an accounting package, and a link to an older warehouse system that has no API. It holds fifteen years of data, and the original developer has moved on.
| Item | Calculation | Person-days |
|---|---|---|
| Simple workflows | 8 × 3 days | 24 |
| Complex workflows | 4 × 10 days | 40 |
| Reports | 6 × 2 days | 12 |
| Accounting integration (API) | 1 × 4 days | 4 |
| Warehouse integration (no API) | 1 × 12 days | 12 |
| Build subtotal | 92 | |
| Data migration | ~33% of build | 30 |
| Discovery, testing, rollout | ~45% of 122 | 55 |
| Base estimate | 177 | |
| Range with uncertainty | ×1.2 to ×1.5 | 210–265 |
That's roughly 42–53 person-weeks. A team of three would deliver it in about four months, which is consistent with what we see on full rebuilds for SME-scale operations.
Turning effort into a budget
To convert effort into cost, multiply person-days by a blended day rate for the team you'd use. Rates vary widely by market, seniority, and whether you're hiring a firm, contractors, or staff, so use figures from quotes or hiring you've seen locally rather than a global average. In the example above, the budget is 210–265 days multiplied by that rate.
Then add the running cost. Hosting, support, and ongoing changes typically cost 15–20% of the original build each year. That figure matters when you compare modernisation against keeping the old system, or against a SaaS subscription.
How to bring the number down
If the range is larger than your budget, don't cut testing or migration. Reduce the scope instead. Focused modernisation, which replaces the one or two workflows causing the most friction first, is almost always where we recommend starting. It might run 4–8 weeks rather than 4–6 months, it puts part of the business on a modern system quickly, and it gives you real evidence of what the rest of the modernisation will involve before you commit to it. Spread over time, a phased approach costs a little more than doing everything at once, but it reduces risk considerably.
Run the method on just those workflows and you'll usually find a first phase that fits.
Weigh it against the cost of doing nothing
An estimate only means something next to the cost of staying where you are. That cost is harder to put a number on, but it's real:
- Single-developer dependency. If the system was built by one person who is no longer available, every change depends on finding someone who understands code written a decade ago. That gets more expensive and more fragile every year.
- Lost productivity. Our audit of a global chemicals manufacturer found that users had stopped submitting change requests because the process was too slow, and had built spreadsheet workarounds instead. The management overhead and data quality risk were ongoing and compounding.
- Missing capability. Legacy systems can't easily support AI, real-time reporting, or remote access. As those become necessities, the gap widens, and modernising now is cheaper than modernising in an emergency three years from now.
To put a rough figure on the first two, estimate the hours your team spends each week on workarounds, re-keying, and chasing data, and multiply by a loaded hourly cost. Over three to five years, that number is often closer to the modernisation budget than people expect.
What to do with your estimate
Your estimate won't replace a discovery phase, but it does three useful things. It tells you whether modernisation is in the right order of magnitude for your budget. It gives you a baseline for judging quotes: when one comes in far below your range, ask what's excluded. And it gives you a clear inventory, which makes any conversation with a supplier faster and any estimate they give you more accurate.
If you'd like a second opinion on your numbers, a free 30-minute call is enough to go through your inventory, point out what's likely to be underestimated, and give you a realistic sense of what the project would involve.
To see how the numbers play out on a real project, this manufacturing case study shows how a phased modernisation was scoped and delivered without disrupting operations.