You have an application that still runs the business, but it costs more every year and simple changes take months. Legacy application modernisation moves it to a newer platform, architecture or codebase so it’s cheaper to run, safer and easier to change. There’s no single right approach. This guide compares the “R” strategies, with typical timelines, team sizes, cost drivers, risks and where AI actually helps.

Why modernise at all?

• Rising run costs. Old hardware, licences and specialist skills get more expensive every year.

• Security and compliance. Unsupported frameworks and operating systems stop receiving patches.

• Slow change. Simple features take months because the code is fragile and poorly tested.

• Skills risk. The few people who understand the system are retiring or leaving.

• Locked-away data. Modern analytics, APIs and AI need data the legacy system keeps to itself.

How do the “R” strategies compare?

The table combines the 7 Rs popularised by AWS with rebuild, which many teams treat as a separate option.

How do you choose the right strategy?

Many organisations take a two-step path. They rehost or replatform quickly to remove infrastructure risk, then refactor the parts that matter most. For large systems, the strangler fig pattern lets new services replace pieces of the old system behind the same interface, so you avoid a risky big-bang cutover.

What we see in delivery: the rules nobody wrote down

In our modernisation projects, estimates rarely break on the code. They break on business rules that live only in the code and in a few people’s heads: a status field that two departments read differently, or a pricing exception added years ago for one customer. Those rules surface as bugs months into a rewrite, when they’re expensive to fix.

That’s why we run a discovery workshop such as Event Storming before anyone estimates a refactor or rebuild. A few days with the people who use the system every day turns hidden rules into a written model you can test the new system against.

What does legacy modernisation typically cost?

Costs depend on application size, connected systems and data migration. Rates and budgets vary by engagement, so we don’t publish a price list. What you can plan with is effort. Typical team sizes and durations:

• Rehost or replatform a single application: typically two to four people for a few weeks to six months.

• Refactor a mid-sized business application: typically four to six people for 3 to 12 months.

• Rebuild a core business system: typically five to ten people for 6 to 18 months or more.

• Assessment and roadmap: typically 2 to 6 weeks, a small share of the total.

To estimate, multiply team size by duration by your partner’s rate, then add the cost of running old and new systems in parallel. Ask whether a quote includes QA and testing against the old behaviour, data migration, project management and support after cutover. For more on what drives project size, see custom software development costs in Europe.

What are the main risks?

• Hidden business rules. Decades of logic live in code nobody has documented. Discovery workshops surface them before they turn into bugs.

• Data migration. Data quality problems often appear only when data is moved. Plan and rehearse it, using a migration checklist.

• Big-bang cutovers. Switching everything on one weekend is the riskiest option. Prefer incremental releases.

• Scope creep. Modernisation becomes a wish list of new features. Separate like-for-like migration from new scope.

• Parallel running costs. Old and new systems run side by side for a while, so budget for both.

Can AI rewrite legacy code for you?

AI coding assistants have become useful in modernisation work, but their role is often overstated. Where they help today:

• Explaining unfamiliar code and summarising modules for engineers.

• Generating documentation and characterisation tests that capture current behaviour.

• Translating well-bounded modules between languages or framework versions, as a first draft.

• Finding dead code, dependencies and candidate service boundaries.

What they don’t do reliably is convert a large system end to end without human design and review. Generated code can compile and still behave differently from the original, so every change needs testing against the legacy behaviour. The size of the gain depends on code quality, language and test coverage. It’s never a reason to skip architecture and testing.

What does a practical modernisation roadmap look like?

1. Inventory the portfolio and classify each application by business value and technical health.

2. Pick a strategy per application using the criteria above.

3. Build a safety net of automated tests and monitoring before changing code.

4. Start with one application or module that is valuable but not the riskiest.

5. Deliver in increments and retire legacy components as soon as they are replaced.

6. Measure run costs, release frequency and incident rates before and after.

How RUBICON helps with legacy modernisation

Since 2013 we’ve modernised and rebuilt software for clients across Europe and North America and launched 60+ products along the way. We usually start with an assessment and a discovery workshop, then deliver in small increments so the old system keeps running until each piece is replaced. See our software engineering and cloud development services.

We’re about 55 people, 40+ engineers, ISO 27001:2022 and ISO 9001:2015 certified and a Microsoft Solutions Partner for Cloud & AI Platforms. If you’re deciding what to do with an ageing system, our architects can review it with you and suggest a path, with a scoped estimate after a short discovery.

Frequently asked questions