The most common question we get before a first conversation has the most honest answer: it depends. Legacy modernisation projects vary enormously in scope, and the cost varies with them. That answer is useful only if it leads to the right discovery conversation.
This article explains what it depends on, what the main cost drivers are, and how to think about the numbers before you've spoken to anyone.
What drives the cost
Legacy modernisation cost is driven by four main factors: the scope of what needs to be built, the complexity of the data that needs to be migrated, the number of external systems that need to integrate, and how much of the existing codebase or architecture can be preserved versus rebuilt.
Each of these can vary by an order of magnitude. A focused modernisation, such as replacing one brittle component with a cloud-native equivalent, clean data, and no integrations, is a very different project from a full platform rebuild that involves migrating 20 years of data from a legacy database, integrating with an ERP, and maintaining operational continuity throughout. The same label, "legacy modernisation," covers both.
Scope
Scope is the clearest driver. Are we replacing a single workflow that's causing the most friction, or rebuilding the entire platform? The first project might run 4–8 weeks. The second might run 4–6 months. Both are valid, and the right choice depends on what the business actually needs and what risk tolerance it has for disruption.
Focused modernisation is almost always where we recommend starting. A scoped project delivers a working system faster, creates less disruption, and gives you real evidence of what the broader modernisation should look like before you commit to it. The phased approach costs more spread across time than doing everything at once, but it reduces risk considerably, and it means the business is running on a modern system within weeks rather than waiting for a multi-month project to complete.
Data migration
Data migration is the cost driver that most clients underestimate. Moving data from a legacy system sounds like a technical task, but it almost always involves data quality problems that have accumulated over years. Fields that were used inconsistently. Records that were entered in multiple places and never reconciled. A schema that made sense in 2005 and doesn't map cleanly to what's needed now.
In our experience, data migration work can account for 20–40% of total project cost on projects involving significant historical data. The upside is that the migration forces a data quality improvement that produces downstream value, including cleaner data for analysis, a single source of truth, and the elimination of the fragmentation that was costing management confidence.
Integrations
Each external integration, whether connecting to an ERP, a CRM, a payment system, or a third-party API, adds complexity and timeline. Integrations that sound simple often aren't, because they depend on the other system's API quality, rate limits, data format, and update frequency. A well-documented, stable API might take a day to integrate. A legacy system with no API that requires a custom connector might take two weeks.
The number and quality of integrations required is one of the first things we assess in a discovery phase, because it's often the largest variable in a project estimate.
The cost of delay
The total cost of legacy modernisation only makes sense when compared against the cost of staying with the current system. That cost is harder to quantify, but it's real.
Single-developer dependency risk: if your system was built by one person who is now unavailable, every change and every bug fix depends on finding someone who understands 10-year-old code. That becomes more expensive and more fragile over time.
Productivity loss: our audit of a global chemicals manufacturer found that users had stopped submitting change requests because the process was too slow, and they had built spreadsheet workarounds instead. The operational cost of that fragmentation, in management overhead and data quality risk, was ongoing and compounding.
Missed capability: legacy systems can't easily support AI integration, real-time analytics, or remote access. As those capabilities become operational necessities rather than luxuries, the gap between what a legacy system can do and what the business needs grows wider. Modernisation now is cheaper than emergency modernisation under pressure in three years.
How to think about the number
A meaningful project estimate requires a discovery phase, because anyone who gives you a number without first understanding the system, the data, and the integration requirements is guessing. What we can say is that focused modernisation projects typically run over a period of weeks rather than months, and full platform rebuilds for SME-scale operations typically run over a period of months rather than years.
The most useful thing to do before asking about cost is to get clear on what the actual problem is. Which specific parts of the current system are causing the most friction? What workarounds has the team built to compensate? What would the operation look like if those frictions were removed? That clarity makes a discovery conversation much more productive, and it means any estimate you get will be based on your actual situation rather than a generic approximation.
If you're at the point where you're researching this seriously, the right next step is a conversation. A free 30-minute call is enough to scope whether and how modernisation makes sense for your operation, and to give you a realistic sense of what it would involve.
Before you decide, it can help to see the structure of a real project. This manufacturing case study shows how a phased modernisation was scoped and delivered without disrupting operations.
Related reading