We are in the middle of a legacy application modernization project on our own platform right now. It is a recycling operations system built on SQL Server and ASP.NET, in continuous production since 2003, serving electric utility companies across the United States — a call center application, a web-based customer ordering site, and dashboards for utility program managers. We are moving it from ASP.NET 3.5 to ASP.NET 8.0.

So this article is not written from the outside. It is written from a position most vendors on this subject are not writing from, which is the middle.

Here is what legacy application modernization actually involves, and where it goes wrong.

The reason businesses wait too long

Legacy applications do not fail. That is the whole problem.

The system works. It has worked for fifteen years. Staff know its quirks and have built habits around them. Nothing is on fire, so nothing forces a decision, and the cost of the decision keeps growing quietly in the background.

What eventually forces it is almost never a business case. It is one of these:

The platform underneath reaches end of support. The operating system, the database engine, or the framework hits a date. Suddenly you are running unsupported software to host an application you cannot move — see our guides to Windows Server 2016 end of support and SQL Server 2016 end of support for how quickly those dates arrive.

You cannot hire for it. The pool of developers who will happily maintain a fifteen-year-old codebase shrinks every year, and the ones who will charge accordingly.

Security or compliance. An auditor, an insurer, or a customer’s security questionnaire asks a question the application cannot answer.

A browser or vendor change breaks something. Old web applications depend on behaviour that modern browsers have removed.

If you are reading this because one of those happened, you are in the normal case. If none has happened yet, you are in the better case — and the work is significantly cheaper before a deadline exists.

Four Legacy Application Modernization Strategies

Rehost. Move the application as-is to new infrastructure — new hardware, a VM, or a cloud instance. Fastest, cheapest, changes nothing about the application. Buys time on the infrastructure deadline and nothing else. Legitimate as a first step, dangerous as the whole plan.

Replatform. Keep the application largely intact but update what it runs on — a newer framework version, a supported database, a managed service instead of a self-hosted one. This is the middle path, and it is where most successful projects live.

Refactor. Restructure the code progressively while it stays in production. Slower, lower risk, and it requires discipline to keep going once the urgent part is done.

Rewrite. Start over with the same requirements. Highest risk by a wide margin, and the one businesses most often choose for reasons that feel compelling and turn out not to be.

Why full rewrites go wrong

This is worth being blunt about, because the rewrite is always the emotionally satisfying option.

A system that has been in production for twenty years does not just contain code. It contains two decades of accumulated decisions — every edge case, every exception a customer negotiated, every workaround for a situation that happened once in 2011 and broke everything. Most of that is undocumented. Some of it is not understood by anyone currently at the company.

A rewrite starts from the requirements as anyone can currently describe them. What it necessarily omits is everything nobody remembers to mention. Those omissions do not surface during development. They surface after go-live, as a stream of individually small failures that collectively destroy confidence in the new system.

Meanwhile the old system still needs maintaining, so you are funding two systems and a migration simultaneously, and the rewrite’s timeline slips because the team keeps getting pulled back.

Rewrites do succeed. They succeed when the scope is genuinely small, or when the business process itself is changing anyway so fidelity to the old behaviour is not required.

The Legacy Application Modernization Approach That Usually Works

Replace the legacy system piece by piece while it keeps running, rather than building a replacement alongside it and switching over on one day.

In practice: pick one function, build it in the new stack, route traffic for that function to the new code, and retire that part of the old system. Then the next. The old and new systems run together throughout, sharing a database in most cases, and the old system shrinks until there is nothing left. In many legacy application modernization projects, keeping the existing database can reduce risk significantly.

The advantages are real. Every step ships something, so value arrives continuously instead of at the end. Each step is individually reversible. And you discover the undocumented behaviour one piece at a time, when the scope of the surprise is small.

The cost is that it takes longer in total and requires the integration layer between old and new to be maintained throughout. That is a genuine trade, not a free lunch.

The database is usually the thing worth keeping

A point that gets missed in modernization conversations that focus on application code.

In most long-lived business systems, the database schema is the most valuable and most stable asset. It encodes what the business actually is — the entities, the relationships, the rules. The application code around it has been rewritten in style two or three times already.

That has a practical consequence: you can frequently modernize the application layer while leaving the data layer intact, which removes the single riskiest part of the project. Data migration is where modernization projects lose data and trust.

It also means the database deserves its own assessment. Twenty years of schema changes accumulate their own problems — and if the engine underneath is also aging, that is a separate project with its own deadline. Our SQL Server consulting guide covers how to assess that side.

Testing when there is no specification

The hardest practical problem in modernization: how do you verify the new system is correct when the definition of correct is “whatever the old one did”?

What works:

Run both systems against the same inputs and compare outputs. Tedious, and the most reliable signal available. For a reporting or calculation-heavy system it is close to essential.

Capture real production behaviour before you change anything. Log actual inputs and outputs from the live system for a representative period. That log becomes your test suite, and it includes the edge cases no specification would have contained.

Involve the people who use it daily. They know which outputs look wrong in a way no automated test will catch. Their reaction to a new screen is data.

Keep the old system available and runnable after cutover, for longer than feels necessary. The ability to check what the old system did about a specific case is worth the licensing cost.

Sequencing that does not blow up

1. Inventory and assess. What does the application do, what does it run on, what depends on it, what are the platform deadlines. This stage produces the finding that reshapes the plan.
2. Stabilise the platform first if a deadline is close. Rehost to buy time. Do not attempt a modernization under deadline pressure — that is how rewrites get chosen.
3. Instrument the existing system. Capture behaviour before changing it. You cannot recover this data later.
4. Choose the strategy per component, not for the whole system. Some parts deserve a rewrite; most do not.
5. Ship the first slice small. Pick something real but low-risk, and use it to prove the integration approach works.
6. Keep going. The common failure is stopping after the urgent part, leaving a half-modernized system that is harder to maintain than either endpoint.

Where ITsoft fits

We build and maintain database-driven web applications, Windows applications, and mobile applications for U.S. businesses, and we have been supporting some of them for over twenty years — which is how we know what the twentieth year looks like. Our software and web development work covers assessment, replatforming, and incremental modernization, and our Microsoft SQL Server database development work covers the data layer underneath.

We are doing this on our own platform right now, which means we are making these trade-offs with our own money and our own customers, not just recommending them.

Talk to Mike Treat about a modernization assessment — we will document what your application runs on, what its real deadlines are, and which components warrant which strategy. You keep the assessment regardless.

Related reading: SQL Server consulting · Windows Server 2016 end of support · SQL Server 2016 end of support