The COO of an insurer has the third regulatory change of the year on the desk, and it has to go into the policy administration system. The system is well over a decade old, runs on a framework nobody teaches any more, and the two engineers who understand its core will retire within a year. Every change takes a quarter, testing is manual, and releases happen once every two months on a Saturday night. The CTO knows the system has to be modernised. So does the board, but it asks two questions nobody can answer well: what will it cost, and can the company keep operating normally while it happens?
Those are fair questions, and the worst answer is a single figure and a single date. Modernisation projects that promise to replace the whole system within a year for a fixed sum often end the same way: eighteen months later the company is running two systems, the new one cannot yet do everything the old one did, and the budget is gone. Modernisation that works looks different. It is a series of smaller stages, each with its own cost, its own business outcome and a point at which you can stop.
We have already written about when to rebuild, refactor or replace a legacy system, with a decision matrix for that choice, and published a legacy modernisation checklist. This article is for a CTO who has already decided to modernise and needs two things: a staged plan that does not stop the business, and a way to build the budget before talking to vendors.
Why is legacy modernisation a budget decision today, not just a technical one?
Because the cost of staying on the old system keeps rising, even if it never appears as a separate line. It rises in the time every change takes, in the risk of losing the last people who understand the system, in licence and support fees for old platforms, in security gaps that can no longer be patched, and in the features the business never gets because the team spends all its capacity keeping the lights on.
The US public sector, which measures its own costs regularly, shows the scale well. In report GAO-19-471 from 2019, the US Government Accountability Office noted that of the more than $90 billion the federal government planned to spend on IT that year, about 80 percent went on operating and maintaining existing systems. GAO analysed 65 legacy systems and identified the 10 most critical, which were between 8 and 51 years old. Private companies do not publish such figures, but the mechanism is the same: the older the system, the larger the share of the IT budget spent on keeping it running and the smaller the share spent on gaining an edge.
That is why the board conversation is best started not with the cost of modernisation but with the cost of the status quo. How long does a typical change take today, and what does it cost? What does support for the old platform cost now, and what will it cost in two years? What happens if two key people leave? Which business initiatives cannot be delivered on the current system? These figures are rarely precise, but even rough ones change the question from “can we afford to modernise?” to “can we afford not to?”
The second reason it is a budget decision is more practical: staged modernisation lets you spread spending over time and fund later stages from the savings and gains of earlier ones. That is a very different conversation with the CFO than a request for a one-off, multi-year budget for a project whose result will only show at the end.
What are the modernisation options: rehost, replatform, refactor and the rest?
The most widely used classification of options is the 7 Rs model popularised by AWS. The AWS Prescriptive Guidance describes seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. Although the guide is about cloud migration, the same vocabulary describes modernisation decisions in general.
Rehost, or lift and shift. The application moves to new infrastructure with no code changes. It is the fastest and cheapest option. It solves infrastructure problems (end of hardware support, data centre costs) but changes nothing about how hard the system is to develop.
Replatform. Limited changes to take advantage of a new platform: moving to a managed database, moving to containers, upgrading the runtime. The architecture stays, but maintenance costs and infrastructure risk go down.
Refactor, or re-architect. Changing the application’s architecture, for example extracting services from a monolith or rebuilding modules so they can be developed independently. AWS explicitly calls this the most complex and costly strategy, and for large migrations recommends moving the application with a simpler method first and modernising it after the migration.
Repurchase, retire, retain. Some functions of the old system are best replaced by an off-the-shelf product, some switched off because nobody uses them, and some left as they are because they work and do not block the business. These three options are often overlooked, yet they do the most to lower the total cost: every module that does not need rebuilding frees money for the ones that do.
The rebuild, refactor or replace decision is covered in detail in the articles linked above. The key point here is that these options are not mutually exclusive across a whole system. A good modernisation plan assigns them to individual modules.
How do you choose a strategy for each module rather than for the whole system?
The most expensive mistake in modernisation is one decision for the whole system: “we rewrite everything” or “we move everything to the cloud”. Legacy systems are not uniform. They have modules that are stable and rarely change, modules that change every month and block the business, and modules almost nobody uses any more.
A practical method starts with a map of the system on two axes: business value and change frequency on one, technical condition and risk on the other. A module that changes often, carries high value and is in poor condition is a candidate for refactoring or extraction first. A stable, rarely changed module in tolerable condition is usually best moved (rehost or replatform) and left alone. A low-value module is a candidate for retirement, and a function that off-the-shelf products do well, document workflow or payroll for instance, is a candidate for repurchase.
The map needs data, not opinions. Repository history shows which modules change most often. Tickets and incidents show where the problems are. A code audit shows the technical condition, dependencies and technical debt in each part. Conversations with business users show where the system really slows the company down. Our technical debt checklist can help structure the first questions.
The result is a list of modules, each with a strategy and a place in the sequence. That list is the basis of both the staged plan and the budget, because the cost of modernisation is in practice the sum of the costs of individual modules plus the cost of the infrastructure that lets them coexist.
What is the strangler fig pattern, and why does it let you modernise without stopping the business?
The name comes from strangler figs, which grow on a host tree and gradually replace it. Martin Fowler described the approach in Strangler Fig Application as an alternative to replacing a system in one step: you start with small additions, often new features, built alongside the legacy code base, and then move pieces of behaviour from the old system into the new one. Fowler notes that the transitional code that lets the two systems coexist has a cost, but that the cost is worth paying for lower risk and earlier value.
In practice it works like this. An intermediate layer sits in front of the old system: an API gateway, a proxy or an integration layer through which traffic passes. At first it forwards everything to the old system. When the first module has been rebuilt and tested, the layer starts routing part of the traffic to it, for example for one customer group or one type of transaction. Once the new module has proved itself in production, it takes over completely, and the corresponding part of the old system is switched off.
Why does this let the business keep running? Because at every moment there is a system handling every process, and every change is small and reversible. If a new module misbehaves, traffic goes back to the old one within minutes, not after weeks of fixing. The business sees progress every few months, not after two years.
The strangler fig also has limits worth knowing before you start. It needs an intermediate layer and transitional code that have to be built and maintained. It is harder when the old system has no clear entry points and the business logic lives in database stored procedures. And it requires discipline: if nobody makes sure old parts are switched off, after a few years the company has two systems instead of one. Similar questions arise when breaking up a monolith, which we cover in our monolith to microservices migration guide.
What does a staged modernisation plan look like, from assessment to decommissioning?
The plan below is a framework to adapt to your own system. Each stage has a goal, a deliverable and a decision point on whether to continue.
Stage 0: assessment and system map. An audit of code, architecture, infrastructure and data, an inventory of integrations, and interviews with users and process owners. Deliverable: a module map with assigned strategies, a risk list, an outline staged plan and a budget estimate in ranges. This usually takes a few weeks, and it is the only stage worth buying at a fixed price before committing to anything more.
Stage 1: foundations. Characterisation tests around critical paths, meaning tests that pin down the system’s current behaviour before anyone changes it. An automated deployment pipeline, monitoring, and the intermediate layer for routing traffic. Often also a rehost or replatform of the whole system if infrastructure is an urgent problem. This stage delivers no new features, but without it every later stage is risky.
Stage 2: pilot. Modernisation of the first module: one with high business value but limited dependencies. The pilot tests the whole approach in practice: the target architecture, the data migration method, traffic routing and how the teams work together. Its real cost and duration are the best basis for pricing the stages that follow.
Stage 3: further modules. Modernisation of the next modules in the agreed order, each with its own budget and acceptance criteria. After each module it is worth revisiting the plan: business priorities change, and some modules may turn out not to be needed.
Stage 4: decommissioning the old system. The last modules, migration of the remaining data, archiving historical data in line with legal requirements, and switching off old infrastructure and licences. This stage is often missing from plans, yet it is the one that delivers the savings that justified the whole modernisation.
A plan like this has one important property: after each stage the company is better off than before, even if the next stage never happens. That is the fundamental difference from a big-bang project, where value appears only at the end, if at all.
What does legacy modernisation cost, and what drives the price?
There is no honest answer on price without assessing the specific system, and a vendor who names a figure after one meeting is guessing. What can be stated precisely is what moves that figure. The table below sets out the main factors and how to check them.
| Price driver | What pushes the cost up | What brings it down | How to check before pricing |
|---|---|---|---|
| Knowledge of business rules | Rules exist only in code, authors have left | Documented processes, available domain experts | Interviews with process owners, documentation review |
| Data | Large volumes, poor quality, many formats | Clean, documented data, single source | Data profiling on a sample |
| Integrations | Many systems, undocumented interfaces, file exchange | Documented APIs, few touchpoints | Integration inventory with owners |
| Tests | No automated tests, manual testing only | Existing regression tests on critical paths | Coverage report, list of test scenarios |
| Logic in the database | Stored procedures holding business rules | Logic in the application layer | Review of schema and procedures |
| Strategy per module | Refactor everything | A mix of retire, retain, rehost and refactor | Module map with assigned strategies |
| Availability requirements | Zero downtime, continuous operation | Acceptable maintenance windows | Agree acceptable interruptions with the business |
| Regulatory requirements | Audits, archiving, system validation | No special requirements | List of legal and industry requirements |
| Parallel running period | Two systems maintained for a long time | Modernised parts switched off quickly | Decommissioning plan in the schedule |
Two rows usually weigh most. The first is knowledge of business rules: if the only description of how the system calculates a premium or a discount is ten-year-old code, someone has to reconstruct that knowledge before anyone builds a new module, and that costs more than the programming itself. The second is data: in many modernisations, data migration is the most time-consuming and most underestimated element.
How do you estimate a modernisation budget in stages?
A modernisation budget is best built the same way the modernisation is delivered: in stages, with increasing accuracy. The example below shows the method and orders of magnitude based on the rates on our own pages; it is not a price for a whole project.
Stage 0: assessment. At ARDURA Consulting the Code Health Audit starts from €4,500 and takes 1–2 weeks, and Technical Due Diligence, which adds scalability, infrastructure and open-source licence compliance, starts from €8,500 and takes 2–3 weeks. For a legacy system about to be modernised, the second option is often the better fit, because modernisation is about more than the code.
Stages 1 and 2: foundations and pilot. Here it is best to cost a team over time. Our Software development page puts a dedicated team from about €14,500 a month. A composition of two senior developers and a senior QA engineer at our 2026 benchmark rates (about €335–485 per day for a senior developer and €335–465 for a senior QA engineer) comes to roughly €20,100–28,700 a month at 20 working days. If foundations and the pilot take such a team four months, that is about €80,400–114,800. On top of that come infrastructure costs and your own people’s time: domain experts, business testers and administrators.
Stage 3: further modules. Here the estimate rests on the pilot’s results. If the first medium-sized module took the team three months and the following modules are of similar complexity, you have a real unit to multiply instead of a guess. That is why this stage’s budget is best approved only after the pilot, in ranges rather than a single figure.
Stage 4: decommissioning. An item that is easy to forget: migrating the remaining data, archiving, and winding down licences and infrastructure. It is also where the savings appear, and they belong on the income side of the budget: no more support fees for the old platform, lower infrastructure costs, less team time spent on maintenance.
A budget like this has two advantages in the board conversation. First, the board approves at the outset only what can be priced reliably: the assessment and the pilot. Second, after the pilot, the decision on further stages rests on facts from your own system, not on a vendor’s promises.
How do you migrate data without downtime?
Data migration is where modernisations most often overrun their budgets and schedules. The old system has collected data for years, often in formats and structures that reflect old requirements, with duplicates, exceptions and fields used for something other than their names suggest.
The first step is data profiling: before anyone designs the migration, you need to know how many records there are, of what quality and with what exceptions. Profiling a sample costs little and avoids discovering halfway through that a third of customers have invalid addresses and transaction history from before an earlier system change sits in a different format.
The second step is choosing how to keep data in sync during the transition. With the strangler fig approach the old and new modules run at the same time, so data has to be consistent in both places. The usual tools are change data capture, which carries changes from the old system to the new one almost in real time, or writing to both systems at once through the intermediate layer. Each has its own costs and risks, but both allow traffic to be switched without a long maintenance window.
The third step is data reconciliation. After migration and during parallel running, data in both systems has to be compared regularly: record counts, checksums, the results of the same calculations. Discrepancies are inevitable; what matters is detecting them automatically and early, not from a customer who received two different invoices.
The fourth step is deciding what to do with historical data. Not everything has to move into the new system. Data needed only for archival or regulatory purposes is often cheaper to move into a readable archive than to migrate into the new data model.
How do you keep the business running during modernisation?
Modernising without stopping the business is not only about architecture; it is also a set of practices that protect the company from the consequences of mistakes during change. Business continuity has to be planned for every stage, not just for the final cutover.
The most important practice is reversibility. Every switch of traffic to a new module should have a simple, tested way back: a switch in the intermediate layer, a feature flag that turns off the new path, or the ability to route traffic back to the old system. If rolling back requires deploying a new version, it is not fast enough.
The second practice is gradual cutover. Instead of redirecting all traffic at once, you start with a small group: internal users, one branch, a few percent of customers. At each step you watch errors, performance and agreement with the old system’s results. Only when the indicators are stable do you increase the new module’s share.
The third practice is parallel running for critical processes. For calculations where an error has serious consequences, such as premiums, interest or payroll, it is worth calculating the result in both systems for a while and comparing them before the new system takes over responsibility. It costs money, but less than correcting thousands of wrong documents.
The fourth practice is freezing changes in the old system in the areas being modernised. If the maintenance team changes a module that another team is rebuilding, the two versions drift apart and the migration never ends. Regulatory changes that cannot wait then have to go into both places, and the budget has to allow for that.
Which questions should you ask a modernisation vendor, and what belongs in the contract?
Choosing a modernisation vendor means choosing a method, not just a team. These questions help you judge whether a vendor has experience modernising without downtime, or only building new systems.
How do you price modernisation before assessing the system? A good answer: a paid assessment at a fixed price, then a price for the pilot, and further stages after the pilot. A vendor who quotes a fixed price for the whole modernisation after a few meetings is either loading it for risk or planning to recover the difference through scope changes.
How will you preserve business rules that exist only in the code? Look for answers about characterisation tests, code analysis and working with domain experts, not about “gathering requirements from scratch”.
What will traffic cutover and rollback look like? The vendor should describe the intermediate layer, gradual cutover and the rollback procedure before talking about the new architecture.
How do you migrate data and check its consistency? The answer should cover profiling, synchronisation during the transition and automated reconciliation.
In the contract, make sure each stage has its own scope, acceptance criteria and budget; that intellectual property passes to you continuously rather than at the end of the project; that code, documentation and infrastructure sit in your accounts from day one; and that after any stage you can end the engagement with a documented handover. Modernisation takes a long time, and a lot can change along the way, including the vendor, so exit terms matter more here than in an ordinary project. What a mid-project vendor change looks like in practice is covered in switching software vendors mid-project.
Which mistakes raise the cost of modernisation the most?
A handful of mistakes recur in modernisation projects often enough to be worth knowing before you start.
Replicating the old system one to one. The team carries over every function, including ones nobody uses, and every quirk that began as a workaround for old limitations. The result is a new system as complicated as the old one, only more expensive. Before rebuilding each module, check which functions are actually used.
No tests before changes. Modernising without tests that pin down current behaviour means nobody knows whether the new module does the same as the old one. The discrepancies surface in production, in front of customers.
Underestimating data. A migration planned as a single step at the end of the project, with no profiling and no transition period, is the most common cause of missed deadlines.
Scope growth along the way. Modernisation becomes the occasion to deliver every postponed business idea. Each may make sense, but together they turn a project with a clear goal into one with no end. It is better to separate modernisation from functional development and add new features only to modernised modules.
Not switching old parts off. When nobody owns decommissioning the modernised parts of the old system, the company pays for both systems longer than necessary, and the savings that justified the project never arrive.
How does ARDURA Consulting support legacy modernisation?
We deliver legacy modernisation through our Software Rescue service, which covers among other things migrating from monolith to microservices, upgrading frameworks and moving to the cloud. We always start with an assessment, because without it every price and every schedule is a guess: the Code Health Audit starts from €4,500 and takes 1–2 weeks, and Technical Due Diligence starts from €8,500 and takes 2–3 weeks. The result is a report with a risk assessment and an action plan, which is yours whoever carries it out.
Our rescue and modernisation work is done by senior engineers only, people who have seen many codebases and know how to navigate legacy systems. If after the assessment you decide to modernise with us, we can do it through Software development as a dedicated team, or strengthen your own team with specialists through staff augmentation, with a two-week satisfaction guarantee and a free replacement. If you prefer to carry out the plan yourself or with another vendor, the report and the staged plan are yours.
What should you remember before approving a modernisation budget?
Modernising a legacy system does not have to be a multi-year project with one figure and one date that stops the business. It can be a series of stages, each costing what can be priced reliably and each leaving the company in a better place.
Remember five things. First, start with the cost of the status quo, because that is what justifies modernisation to the board. Second, choose a strategy for each module separately: rebuild some, move some, buy some and switch some off. Third, modernise incrementally, with the strangler fig pattern, an intermediate layer and a way back at every cutover. Fourth, budget in stages: a paid assessment, a pilot, and only then pricing for further modules based on what the pilot showed. Fifth, treat data migration and decommissioning as full stages with their own budgets, not add-ons at the end.
If you are planning a modernisation and want to start with a reliable assessment of the system, see the code audit and Technical Due Diligence packages or book a call. We will tell you which kind of assessment fits your system and what the first stage of modernisation could look like.