Application modernization strategies: the 7 Rs, strangler fig and the dates that force your hand

The main application modernization strategies are the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor or re-architect. Pick one per application, based on its business value and risk, and modernize large systems in slices with the strangler fig pattern rather than a big-bang rewrite. End-of-support dates often decide the timing.

Most guides on this topic list strategies without telling you when each one fits, and some invent their own "Rs" or promise "zero downtime". This one uses AWS's published 7 Rs with its own use cases, Microsoft's guidance on the strangler fig pattern (including when not to use it), and a calendar of support deadlines checked on 23 October 2026. Several of those dates land in the next three months, so check them again before you plan: .NET dates in particular should be rechecked after 10 November 2026.

What are the 7 Rs of application modernization?

AWS Prescriptive Guidance describes seven migration strategies, "known as the 7 Rs". They were written for cloud migration, but they work as a modernization vocabulary because each one is a different answer to "what do we do with this application?"

Two AWS details are worth knowing. First, AWS suggests looking at retiring "zombie applications" with average CPU and memory usage below 5%, and "idle applications" between 5% and 20% over 90 days. Utilisation data from a discovery tool shows which applications qualify. Second, AWS states that refactor "is not recommended for large migrations", because it modernizes during the move. Its advice is to rehost, relocate or replatform first, then modernize once the migration is complete.

How to choose per application

Score each application on two axes, then let the scores suggest a strategy:

Add a third question: is there a deadline? An end-of-support date (see the calendar below) can push an application to rehost or replatform now and refactor later.

Is rehosting modernization?

No. Rehosting changes where an application runs, not how it's built. Microsoft's Cloud Adoption Framework Modernize guidance puts it plainly: "A rehost migration alone isn't modernization."

Rehosting still has a place. It can get you out of a data centre, onto supported infrastructure and into an environment where later changes are easier. The mistake is to declare the job done after the move. Plan the next step for each rehosted application before you migrate it: replatform the database, containerise the app, or refactor the parts that change most often. Our cloud migration work covers the move; application modernization covers what comes after. For the move itself, use our cloud migration checklist.

What is the strangler fig pattern?

The strangler fig pattern replaces a legacy system piece by piece. Martin Fowler named it after the strangler fig, a vine that sprouts on a host tree and grows until its roots reach the ground and it can sustain itself; his Strangler Fig Application article (updated 22 Aug 2024) describes building the new system around the edges of the old one until the old one can be removed.

Microsoft's Azure Architecture Center (updated 16 Oct 2026) describes the mechanics in four phases:

1. Add a façade. A proxy sits between clients and the legacy system. At first it routes almost everything to the old system.
2. Move functionality in slices. You build a feature in the new system and the façade starts routing those requests to it. Each iteration moves more.
3. Decommission the legacy system once nothing depends on it.
4. Remove the façade and let clients talk to the new system directly.

How to do it well

• Find the seams. Pick slices with clear boundaries: a module, a business capability, a set of screens or an API. Domain boundaries work better than technical layers.
• Start with a slice that matters but won't sink you. High enough value to prove the approach; low enough risk to survive mistakes.
• Keep the façade healthy. Microsoft warns that the façade must keep up with the migration and must not become "a single point of failure or a performance bottleneck". Monitor it like production infrastructure, because it is.
• Use an anti-corruption layer. While both systems coexist, the new system may need to call unmigrated legacy features, and vice versa. Microsoft recommends the anti-corruption layer pattern: an adapter that translates between the two, so legacy conventions don't leak into the new design.
• Write characterisation tests first. Before moving a slice, capture what the legacy system actually does today, including the odd behaviour users depend on. Our software testing team often starts modernization projects this way.

When should you not use the strangler fig pattern?

The pattern isn't always right. Microsoft's guidance lists situations where it might not be suitable:

• Requests to the back end can't be intercepted, so there's nowhere to put a façade.
• You can't access the legacy source code and it has no other integration point you can change, such as its database.
• The system is small and replacing it whole is simple.
• You need to decommission the original quickly, because the pattern assumes both systems run side by side for an extended period.

We'd add one more: when the organisation can't fund two systems in parallel. Strangler fig spreads the cost and the risk, but you pay for the old and new systems at the same time until the end. If that's not possible, a well-tested, phased replacement or a repurchase may be the better route.

How do you modernize a shared legacy database?

The database is usually the hardest part, because many legacy applications share one large database across business domains. Microsoft's strangler fig guidance gives a three-step approach for extracting one domain at a time:

Microsoft's advice is to treat removing legacy objects as a deliberate final step, only after the new system is validated. Where business logic lives in stored procedures, the database itself can send messages to new services, or CDC can read the transaction log, so you don't have to change legacy application code. For moving the data itself, see our data migration checklist.

Which deadlines force the decision in 2026–2027?

Support dates turn "someday" into a project plan. These were checked on 23 October 2026 on the vendors' own pages.

What to do with each:

• .NET 8 or 9 apps: usually a straightforward upgrade to .NET 10, not a rewrite. Test it, then ship it. Our .NET development team handles these upgrades.
• .NET Framework 4.6.2: move to a later supported .NET Framework version as a short-term fix, or port to modern .NET as part of a replatform.
• SQL Server 2016 and Windows Server 2016: replatform the database to a supported or managed version; rehost the servers if you need time.
• PHP 8.2 and Python 3.10: upgrade the runtime and dependencies; the hard part is usually old libraries, not your code.
• Java estates: check your vendor's support dates for your exact distribution and version; our Java development team can assess the upgrade path.
• Windows 10 desktops running line-of-business apps: if the app ties you to old machines, a modern desktop app or a web app may be cheaper than years of ESU fees.

What did GAO find about legacy systems?

The US Government Accountability Office's report GAO-25-107795 (17 Jul 2025) is a useful reality check for any organisation. It found that federal agencies spend more than $100 billion a year on IT, with about 80% typically reported on operations and maintenance. GAO identified 11 of the most critical legacy systems, ranging from 23 to 60 years old. Agencies had modernization plans for 9 of them, but only 3 of those plans included all the key elements GAO looked for, and 2 systems had no plan at all.

The lessons transfer to private companies: most of the budget goes to keeping old systems running, and modernization stalls without a plan that names milestones, the work needed and the system's disposition. Write that plan before you choose tools.

What does a modernization roadmap look like?

1. Inventory. List every application, its stack, owners, users, integrations and support dates.
2. Score. Business value, technical risk and deadline for each.
3. Assign a strategy per application using the 7 Rs. Expect a mix.
4. Retire first. Zombie and idle applications free up budget immediately.
5. Hit the deadlines. Upgrade or replatform anything on the support calendar above.
6. Strangle the core. For the high-value, high-risk systems, plan slices behind a façade, with characterisation tests and a data plan per slice.
7. Measure. Track release frequency, incidents and running costs before and after, so the business sees the return.

How can Elgrith help?

Elgrith has delivered 1,000+ projects for 250+ clients since 2015, from our New Delhi HQ and client-partnership centres in New York, London and Shanghai. Our application modernization team starts with an assessment of your portfolio, assigns a strategy per application, and modernizes the core in slices so the business keeps running. We work across .NET, Java, PHP, Python and front-end stacks, and we pair with our cloud migration team when hosting moves too. You own the code and IP, and you get a fixed written quote after a free call. Book a call or start a project.