Application Modernisation Without a Rewrite

Four horizon tiles stepping up from data access to managed actions, one identity and near-time data, each ticked to show it delivers value on its own

Quick answer: Application modernisation is bringing legacy systems up to date so they are accessible, maintainable and cloud-ready, without rewriting everything at once. The approach we recommend is a sequence of horizons, where each stage delivers value on its own: get at the data, turn it into managed actions, unify identity and access, then move data reliably in near-time. Treat these as functionality families that pay off progressively, not a single leap you cannot stop halfway.

Ask why legacy system modernisation has a reputation for pain, expense and disappointment, and the answer is often the same shape: someone tried to replace everything at once. The big-bang rewrite is a bet the whole organisation makes, pays for over years, and cannot cash until the very end. A 2012 study by McKinsey and the University of Oxford of more than 5,400 IT projects found that large ones run, on average, 45 per cent over budget and deliver 56 per cent less value than predicted. Yet the big-bang rewrite is still the default mental model.

There is a better one. Modernise in horizons, where each stage stands on its own and returns value before the next begins. This is a guide to that approach, drawn from our work on enterprise systems, and it is deliberately platform-agnostic. The sequencing matters more than the stack.

The big-bang rewrite is why modernisation has a bad name

A legacy estate is rarely one system. It is a mix of interconnected services, some in-house and some central, held together by point integrations and a lot of institutional memory. The maintenance overhead is high, the data flows are slow and sometimes unreliable, and every team knows a workaround.

The instinct is to sweep it all away and start again. The problem is that a full rewrite couples every risk together. You cannot ship a third of a big-bang, so you cannot learn a third of the way in. The business case rests on a payoff that arrives at the end, if it arrives at all, and the longer the programme runs the more the ground shifts under it. The same research found that every extra year of schedule added around 15 per cent to the cost overrun.

The alternative is not to be timid. It is to break the work into stages that each earn their keep.

Modernise in horizons, not a single leap

A horizon is a stage of modernisation that delivers a real business benefit on its own, and sets up the next stage without depending on it to be worthwhile. Think of it as paying down the estate in instalments, where each instalment already improves something.

The idea has good company. Martin Fowler’s Strangler Fig pattern describes the same instinct at the code level: move behaviour from the legacy system into a new one gradually, so the old system is retired piece by piece.

We recommend the order below because each horizon makes the next cheaper and lower-risk, but none of them is wasted if you stop after it. Before touching any of it, there is a principle worth stating: when you replace a legacy system, replace the job it did, not the artefact. A paper sign-off sheet is not really about paper; it is an audit trail, a list view and a record of who did what. Digitise the paper and you have missed the point. Preserve the job, in a better form, and you have modernised.

The four horizons

Get at the data before you touch the systems. The first horizon is standardised, on-demand access to the data trapped in existing systems, through modern gateway interfaces instead of brittle point integrations. Nothing is replaced yet. But the moment data is reachable in a consistent way, everything downstream becomes possible, and the estate is already easier to work with. Every later horizon builds on it.
Turn source data into managed actions. With data reachable, the next horizon is a layer that describes the tasks people handle every day (approving a change, chasing an overdue invoice, resolving a stock discrepancy) as actions: things with a state and a workflow, sitting on top of disparate source systems. This is where raw data becomes exceptions-based: instead of a person reading hundreds of pages of a report to find what needs attention, the system surfaces the few things that do, assigns them, and tracks them. The systems underneath have not changed. The way people work with them has.
One identity across everything. The third horizon is a single, universal record of a user: one login for access to the systems they need, with authorisation tailored per person. It removes a whole category of friction and risk, and it is the foundation for governing who can do what as the estate modernises around them.
Move data reliably, in near-time. The last horizon is dependable, low-latency data exchange across the estate and between on-site systems and the cloud, replacing legacy file-based transfers and overnight batches. Reliable near-time information is what makes everything above feel live rather than a day behind.

Functionality families, not a dependency tree

Here is the part that changes how a modernisation programme is governed. The horizons are not a strict dependency tree where nothing has value until the last box is ticked. They are a set of functionality families that can realise business benefit progressively.

That means each domain (pricing, inventory, finance, whatever it is) can move along the same horizons at its own pace. A programme run this way is never all-or-nothing. It is a series of defensible steps, each of which leaves the organisation better off than before, and any of which can be paused without stranding the investment.

In our experience, this is the clearest difference between a modernisation that succeeds and one that stalls: whether benefit is designed to arrive progressively, or deferred to a finish line that keeps moving.

Start where the pain meets the payback

Because the horizons pay off progressively, sequencing becomes a business decision rather than a technical one. The first area to modernise is wherever the pain is sharpest and the return is clearest, usually the process people complain about most and the one that quietly costs the most in manual effort.

Prove the approach there. A first horizon that makes trapped data accessible, or a first action layer that turns a dreaded manual report into a short list of things to action, builds the evidence and the goodwill for the rest. Modernisation funded by its own early wins is far more durable than modernisation funded by a promise.

Sometimes the sharpest pain sits in the layer customers touch, and that layer can be modernised without replacing anything underneath it. When we worked with Assurant, their logistics platform stayed in place behind the scenes, and we used their existing codebase as the foundation for a redesigned trade-in experience across JB Hi-Fi, The Good Guys and Harvey Norman.

Where the small-scale version fits

Not every modernisation is an enterprise estate. Sometimes it is a single spreadsheet, an ageing Microsoft Access database, or a process that has outgrown a low-code tool like Power Apps. The same principle applies at that scale: understand the job the old thing does, and rebuild that job properly rather than porting the mess. If you are weighing whether to buy something off the shelf or build, the off-the-shelf versus custom decision comes first, and our web application versus custom software guide maps the options.

The horizons approach is what the same thinking looks like when the estate is large, the systems are entangled, and a single leap is too big a bet.

The takeaway

Application modernisation fails when it is treated as one enormous leap and succeeds when it is treated as a sequence of horizons that each pay their own way. Get at the data, turn it into managed actions, unify identity, move it reliably in near-time, and let each stage fund the next. Start where the pain and the payback meet, preserve the job rather than the artefact, and never bet the organisation on a payoff that only arrives at the end.

Modernise in instalments, and every instalment leaves you better off.

Since 2008, Conduct has designed and built enterprise systems and modernised the legacy estates behind them, platform-agnostic and sequenced to pay off as you go. For the Microsoft Azure view of the same approach, see our Azure application modernisation guide. If you are facing a modernisation that feels too big to start, talk to us.

Frequently asked questions

What is application modernisation?

It is bringing legacy applications up to date so they are accessible, maintainable and cloud-ready, without necessarily rewriting them from scratch. It can mean re-platforming, re-architecting, exposing data through modern interfaces, or rebuilding the workflow on top of existing systems. The goal is a lower-risk, more capable estate, delivered in stages rather than one leap.

Why do big-bang legacy rewrites fail so often?

Because they couple every risk together and defer all the value to the end. You cannot ship or learn from a third of a big-bang, the business case rests on a payoff that only arrives if the whole thing lands, and the longer it runs the more the requirements shift. Modernising in stages that each deliver value avoids betting the organisation on a single finish line.

What is a horizons approach to modernisation?

Breaking modernisation into stages (“horizons”) that each deliver a real benefit on their own and set up the next without depending on it. A common order is: make trapped data accessible, add an action and workflow layer on top, unify user identity and access, then move data reliably in near-time. Each stage is useful the day it lands.

Where should we start modernising a legacy estate?

Where the pain is sharpest and the payback is clearest, usually the process people complain about most and the one that costs the most in manual effort. Proving the approach there produces the savings and the credibility to fund the next stage, which is far more durable than a programme funded by a promise of value at the end.

Is application modernisation only for large enterprises?

No. The same principle scales down to a single spreadsheet, an ageing Access database or a process that has outgrown a low-code tool: understand the job the old system does and rebuild that job properly, rather than porting the mess. The horizons approach is simply what this thinking looks like when the estate is large and entangled enough that a single leap is too risky.