Legacy System Modernization: The Five Options Compared, From Rehost to Rebuild

Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.

Every established company has at least one system that everybody wants gone and nobody wants to touch. It runs the orders, the claims, the schedules or the invoices. It was written by people who have left, on a platform the vendor stopped supporting, and it quietly blocks every new initiative that needs to talk to it. The question is never whether to modernize it. The question is which of five quite different things "modernize" should mean, and in what order. This post compares the five options on cost, time, risk and fit, and gives a method for choosing one per system rather than one for the whole estate.

What are the five modernization options?

The relative costs use a straight rehost of the same system as 1x. For a mid-sized core system that is roughly $50,000 to $150,000 (€44,000 to €130,000, £37,000 to £110,000), which puts a rebuild in the $200,000 to $600,000 (€175,000 to €520,000, £150,000 to £445,000) band for a core platform and higher for anything enterprise-wide. How much enterprise software development costs has the full bands.

Why decide per system and not per portfolio?

The most expensive mistake in modernization is a single answer for the whole estate. "We are moving everything to the cloud" rehosts systems that needed rebuilding. "We are replacing everything with SaaS" throws away the one system that encodes how the company actually wins. "We are rewriting the platform" turns a stable billing engine into a three-year science project. Each system has its own change rate, its own share of business logic and its own fragility, and those three facts decide the option.

• Change rate. A system that changes weekly earns a refactor or rebuild, because the cost of each change is the thing you are paying for. A system that changes twice a year earns a rehost and nothing more.
• Business logic. A system full of rules nobody has documented is dangerous to rebuild and impossible to replace with SaaS. It wants a refactor that extracts and tests those rules first.
• Fragility. A system that falls over under load or cannot be deployed without a weekend outage wants a replatform before anything else, because every other option depends on being able to deploy safely.
• Differentiation. If the function is how you compete, own the code. If it is payroll, buy it.

How do you map the estate before choosing?

Modernization starts with an honest inventory, and most companies do not have one. For each system, record who owns it, what it does, what it talks to, how often it is changed, how often it breaks, what it costs to run and what the business would lose if it stopped for a day. The exercise takes a few weeks for a portfolio of 20 to 40 systems and is the most valuable deliverable of a discovery phase. It also surfaces the integrations, which is where modernization budgets go wrong. A system with 15 undocumented interfaces is a different project from the same system with two.

Score each system on the four facts above and the options fall out. Then look at the dependencies. A system cannot be rebuilt before the systems that feed it have stable interfaces, which is why an integration layer is often the first thing built in any serious program.

What does the sequencing look like?

1. Stabilize first. Replatform anything that cannot be deployed safely. You cannot modernize a system you are afraid to touch.
2. Put interfaces in front of the core. An API layer between the legacy core and everything else lets you move traffic one function at a time. This is the mechanism behind modernizing without the big bang.
3. Pick a valuable, isolated slice. The first rebuilt piece should matter to the business and have few dependencies. Reporting, a customer portal or a single workflow are common choices.
4. Replace commodities as you go. Where a slice is a commodity, swap in SaaS behind the same interface rather than rebuilding it.
5. Migrate data deliberately. Each slice carries its data with it, rehearsed and reconciled. Data migration from legacy systems is the plan for that.
6. Retire when empty. The old system is switched off when nothing depends on it, not on a date chosen two years earlier.

What goes wrong in each option?

• Rehost becomes permanent. The move was supposed to be step one and it was the only step, so the company now pays cloud prices for a system that still cannot change.
• Replatform finds the undocumented dependency: a file share, a scheduled job on a forgotten server, a hard-coded IP. Budget two weeks of surprises per system.
• Refactor loses its sponsor. Eighteen months of work with no new feature is hard to defend in a budget review, so tie each refactoring slice to a visible outcome, such as a release that used to take a weekend and now takes an hour.
• Rebuild rediscovers the rules. The old system handled a leap-year edge case in a tax calculation and nobody wrote it down. Parallel running, where the old and new systems process the same inputs and the outputs are compared, is the only reliable defense.
• Replace with SaaS bends the business to the product. The 20 percent the product cannot do gets handled in spreadsheets, and three years later there is a new legacy system made of spreadsheets.

Should you rebuild or keep patching?

A useful test: add up what the system cost to change and to keep running over the last two years, including the people who understand it and the initiatives it blocked. If that number over the next five years exceeds the rebuild estimate, rebuild. If not, refactor the parts that change and leave the rest. Technical debt is only worth paying down where the interest is being charged, and in most legacy systems 20 percent of the code takes 80 percent of the changes.

How 7L approaches modernization

7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens. We were founded during the Greek financial crisis and have supported more than one hundred organizations since, a large share of them with systems that had to keep running while they were replaced. We do not sell one option. We map the estate, score each system, and sequence a program that usually mixes a replatform, a few rebuilt slices and a SaaS replacement or two, with an interface layer in front of the core from the start. The enterprise software development guide explains how that fits into a full engagement. If you have a system everybody wants gone, tell us about it and we will tell you which of the five it needs.