How to modernize an old web application without betting the business on a rewrite

This guide is for operations leaders, IT managers and owners whose staff, customers or field crews depend on a web application built for another decade. It covers how to tell modernization from maintenance, why full rewrites stall, and how to modernize page by page without pulling the system out from under the people using it.

The method in six steps:

1. List every page, form, report and integration, and who uses each one.
2. Write down the business rules the old code enforces before you change anything.
3. Rank pages by use and pain. Start with the busiest screens, especially the ones people need on their phones.
4. Decide page by page: keep, refresh, rebuild or retire.
5. Build and test each change on a staging copy with realistic data and the people who use the page.
6. Release in small batches with a way back, and delete old pages once their replacements prove themselves.

Signs your web application needs modernizing (beyond ‘it’s old’)

Age alone isn’t a reason to spend money. An application from 2008 that does its job, gets security updates and is easy to change only needs maintenance. Modernization pays off when the system costs you time, people or risk every week. The real signs your legacy software needs modernization sound like this:

• “Our existing system is difficult to use.” New hires need someone beside them for a week, people keep cheat sheets taped to their monitors, and side spreadsheets exist because the system can’t show what they need.
• “Our contractors need to do this from their phones.” Pages that need pinching and zooming, forms that break on a small screen, and people who wait until they’re back at a desk or call the office instead.
• “Only one person understands it.” The rules that run your operation live in old code and one person’s memory. Every change waits for them, and nobody wants to think about what happens when they leave.
• “It can’t connect to anything.” Orders get retyped into accounting, weekly reports are built by exporting and pasting, and each new tool adds another spreadsheet.
• “We can’t patch it.” The language, framework, server operating system or database no longer gets security updates, or applying them breaks the application.
• “It only works in Internet Explorer mode.” Microsoft ended support for the Internet Explorer 11 desktop app on certain Windows versions on June 15, 2022, and commits to supporting IE mode in Edge “through at least 2029” (Microsoft lifecycle FAQ). That’s a stopgap, not a long-term home.
• “It’s built on a platform nobody supports anymore.” If that platform is Classic ASP, our guide to Classic ASP end of life covers what Microsoft actually says and your options.

Why full rewrites stall, and when one is still the right call

The case for starting over is easy to make: clean code, current tools, no more mystery. The trouble starts once the rewrite is under way.

Why rewrites stall

• The old code is the only complete record of your rules. Years of edge cases (“hold the order if an invoice is over 60 days late, unless the account is flagged”) live only in the code. A rewrite has to rediscover each one, and some get rediscovered after launch, by customers.
• Nothing ships until everything ships. The people using the system see no improvement for months while you pay to run the old system and build the new one.
• The target moves. Either you freeze changes to the old system and the business waits, or you keep changing it and the rewrite chases it.
• Launch day is a cliff. Everyone switches at once, every gap shows up at once, and when something breaks it’s hard to tell which change caused it.

When a rewrite is still the right call

• The business rules no longer match how you work, so carefully preserving them would preserve a process you want to change.
• The platform can’t reasonably be patched or hosted safely, and the code can’t be replaced in pieces.
• The application is small and simple. Microsoft’s architecture guidance notes that the incremental approach might not suit a small system where “replacing the whole system is simple” (Azure Architecture Center).
• The way the data is structured is fundamentally wrong for the business today, so every screen would need to change anyway.

Even then, a rewrite doesn’t have to be one big switch. Rebuilding one module at a time and running it beside the old system keeps most of the safety of a page-by-page migration.

The page-by-page method: modernize while the old system keeps running

Engineers call this the strangler fig pattern, after a plant that grows around a host tree until it can stand on its own. In plain words: you build new pages alongside the old application, move people to each new page once it’s ready, and keep the old system running for everything not yet replaced. Over time the old part shrinks until you can switch it off. Microsoft’s Azure Architecture Center describes it as a way to “incrementally migrate a legacy system by gradually replacing specific pieces of functionality.”

It’s the approach we take to legacy application modernization, because it lets you judge the work on real pages instead of waiting for a launch date.

What the strangler fig pattern looks like in a web application

• A shared foundation first. Layout, navigation and styles that work on any screen size, built so old pages still display correctly beside the new ones.
• One page or workflow at a time. “Check order status” or “submit a job update”, not “the customer module”.
• The same data, at first. New pages read and write the existing database, so old and new screens agree and the reports people rely on keep working. If the database itself is the problem, move it as a separate, planned phase.
• Switch links, keep a fallback. Menus and links point to the new page; the old one stays available until the new one has proven itself.
• Retire as you go. Once a new page is stable, delete the old one and its code so dead pages don’t pile up.

When the full pattern is overkill

The textbook version puts a routing layer (a “façade” or proxy) in front of both systems and sends each request to the old or new version. That machinery earns its keep on large systems with many users and integrations. For a smaller application it can be more than the job needs: modernizing the busiest screens one at a time inside the existing application, testing each on a staging copy and releasing them in small batches gets you most of the benefit.

Where to start: the screens people use most, especially on phones

Start where heavy use and daily pain overlap. To find that spot, you need an inventory.

Build a page inventory

For each page, form and report, note:

• Who uses it (staff, customers, field crews, admins) and on which devices.
• How often it’s used. Server logs or analytics help; if you have neither, ask the people who use it.
• What data it reads and writes, and which reports, exports or other systems depend on that data.
• Rules or quirks that live only in its code.
• The complaints, workarounds and support calls it generates.

An inventory often turns up pages nobody uses anymore. Retire those instead of modernizing them.

Rank by use, pain and risk

If the complaint is phones, see exactly what breaks before you set the scope. Our free mobile-friendly test runs in your browser, including on pages behind a login, and flags the problems. To fix them inside the existing app, see how we make an existing web app mobile-friendly.

Keep, refresh or rebuild: deciding page by page

Not every page needs the same treatment. Give each page in the inventory one of four decisions.

Questions to ask about each page

• Do the rules on this page still match how we work?
• Do people complain about it, or quietly work around it?
• Does anyone need it on a phone?
• Is the code safe to change, and does anyone understand it?
• What else reads or writes the data this page touches?

A useful rule: keep visual changes and logic changes in separate releases where you can. If a release changes both how a page looks and how it calculates, and a number comes out wrong, you won’t know which change caused it.

For a structured version of these questions across the whole application, use our rewrite or refactor scorecard. It scores your application on value, pressure, technical risk, data and readiness, and recommends a path with the reasons behind it.

Releasing without disruption: staging copies, rollbacks, running both

If the goal is to modernize a legacy application without downtime for the people using it, how you release matters as much as what you build. There are three broad ways to move people off an old system:

Test each page on a staging copy first

A staging copy is a private copy of your application that mirrors production: the same configuration, realistic data (with sensitive details masked) and integrations pointed at test accounts. A modernized page goes to production only after it passes there. Check:

• Real phones and tablets, not just a narrowed browser window.
• Each path through the page: successful submits, validation errors, empty states and the odd cases from your inventory.
• The old pages next to it, in case new styles leaked into them.
• Integrations, run against test accounts.
• Reports and exports, to confirm they still get the data they expect.
• Sign-off from a few people who use the page every day. They spot problems no test script will.

Keep a way back

Release each page on its own or in a small batch, and decide how you’d undo it before it ships: a version-control revert, a setting that points the menu back to the old page, or a feature switch. If something unexpected shows up in production, you roll back one page, not the whole application.

Running old and new side by side

• Make the header and navigation consistent early, so the mix of old and new pages doesn’t feel like two systems.
• Redirect old page addresses, so bookmarks and emailed links still work.
• Keep patching old pages until they’re replaced.
• Track progress on a simple list: not started, on staging, live, old page retired.
• Tell the people who use the system what’s changing and when, before it changes.

The next section shows page-by-page modernization on a real system: a contractor portal where each page is tested on a staging copy before production. For more on old systems, portals and stalled projects, browse our guides.