Application Modernization Decision Framework: Six Paths
Quick Answer
The application modernization decision framework sorts a legacy application into one of six paths: retain and remediate, refactor, replatform, rebuild, replace, or retire. Five of the six change the application; retain and remediate is the sixth, a baseline chosen on evidence rather than defaulted into.
Key Takeaways
The application modernization framework has six paths, not five: retain and remediate, refactor, replatform, rebuild, replace, and retire, ordered by how much of the application survives.
Four inputs select the path: application health, business criticality, technical debt against dated dependency support windows, and cost and risk shapes across a fixed horizon.
When inputs conflict, a dated external constraint outranks continuity exposure, which outranks health-based removals; cost shape settles what remains.
Portfolio order is decided by consequence, not convenience: criticality tier, continuity exposure, and the nearest end-of-support date.
Rewrite fear is a rational response to a real pattern: rebuilds overrun when the rules were never written down. Recover the rules before choosing a path.
Rebuild, Replatform, Refactor, Replace, or Retire, How Do We Choose?
The framework uses four inputs to select a path: application health, business criticality, technical debt measured against dependency support dates, and cost and risk shapes across a fixed horizon. When inputs conflict, a dated external constraint outranks continuity exposure, which outranks health-based removals, with cost shape settling remaining questions.
When inputs conflict, cost shape settles what remains.
What This Page Decides, and What It Hands Off
This page determines which of six paths fits a specific application and the sequencing order across a portfolio. Related decisions, engagement structure, delivery method, and platform selection, belong to separate pages.
The Six Application Modernization Paths, Ordered by How Much Survives
Path
Definition
When It Wins
What It Costs
First Test Artifact
Retain and remediate
Keep the application and repair support, security, and ownership gaps around it
Business fit is intact and failures are operational rather than structural
Defers structural change; someone must date the deferral
A support statement listing each unpatched component, its owner, and vendor support end date
Refactor
Improve code and structure in place without changing user-facing functionality
The architecture holds, code is understood, and debt is local
Pays for work no user can see; hardest path to fund
A dependency inventory marking each component supported, unsupported, or unknown with a named owner
Replatform
Modernize runtime and platform with limited functional redesign
The application earns its keep and the underlying stack is out of support
Carries process and data debt across intact to new platform
A hosting and configuration inventory naming current runtime and what a candidate platform must reproduce
Rebuild
Build the capability again on a current stack, keeping business rules and discarding implementation
The requirement is real and implementation blocks needed business changes
Rebuilds undocumented rules; discovery is the schedule risk
A written rules catalogue extracted from the running system with unsourced rules logged as open items
Replace
Meet the requirement with a packaged product or low-code application instead of custom code
The process sits close to market standard and differentiation lives elsewhere
Trades control for vendor roadmap; fit gaps surface after signature
A gap list scoring the candidate against the rules catalogue, marking each rule met, configurable, or absent
Retire
Switch the application off after moving or archiving its data and reassigning remaining capability
Usage has collapsed or another system already holds the capability
Someone loses a report; the archive and sign-off are the actual work
A usage and data record: sign-ins across twelve months, reports reading from it, and data destination
Application Health and Who Can Still Change the Code
Health is measured on two axes: what the code can still do, and what your organization can still do to the code. The relevant questions include when the last change was deployed and by whom, whether the team can rebuild the application from source today, and whether change estimates come from reading code or guessing.
Patchability is the underlying signal. An application whose runtime, framework, or third-party components can still take security updates sits in a different category from one that cannot be patched.
Business Criticality and Business Continuity
Rank criticality by first-hour, first-day, and first-week consequences. Business continuity measures what the business does during the change, not just what it loses if the application stops. The Strangler Fig pattern applies where an application has no room to stop: functionality moves piece by piece to new applications and services until the old system is decommissioned.
Technical Debt and the End-of-Support Date
Three numbers make the debt rate visible: change lead time against the median for comparable systems, the share of engineering hours spent on defects and workarounds, and the count of requested changes withdrawn because the estimates came back too high.
End-of-support dates are facts with calendar entries, not judgments. Build a dated dependency list covering operating system, runtime, framework, database engine, commercial components, and retiring integration endpoints.
When the Application Runs on .NET Framework
The framework support dates set the outer bound. .NET 8 support ends November 10, 2026. .NET Framework 4.8 and 4.8.1 have no published end date. .NET Framework 4.6.2 support ends January 2027.
Technology
Microsoft Documentation
Path Implications
Class libraries, Console tools, Windows Forms, WPF
Available in .NET but remain Windows-only; Windows Compatibility Pack provides a large API surface
Usually a replatform, with the application staying on Windows
ASP.NET Web Forms
A time-consuming task that requires planning; many Web Forms controls may not have exact counterparts in Blazor
The user interface is rebuilt; separated business logic moves with less change
WCF services
CoreWCF NuGet packages support .NET 6 and later
A port to test by building against target, not an automatic rewrite
.NET Remoting
Not supported on .NET 6 and later; use inter-process communication alternatives
A replacement, priced as its own line item
Application domains
Use separate processes, containers, or the AssemblyLoadContext class
A replacement
Code access security
No longer a security boundary; use OS-provided boundaries
A design change; in regulated environments, the control evidence also changes
COM+ and Windows Workflow Foundation
Not supported in .NET 6 and later
A replacement
Cost Shape and Risk Shape
Every path carries three cost components: a one-time build or move cost, a recurring run cost covering hosting, licensing, support, and engineering capacity, and a deferral cost that combines current run cost with remediation.
They require opposite responses.
Delivery risk is that work costs more or takes longer than planned. Continuity risk is that business is harmed during the change. They require opposite responses: delivery risk calls for cutting scope early; continuity risk requires parallel running and rehearsal.
Rewrite fear is the honest name for what stalls these decisions, and it is a rational response to a real pattern rather than a failure of nerve. Rewrites overrun when the rules were never written down.
Modernization With the Architecture Decided First
i3solutions delivers modernization across Microsoft 365, Azure, and Power Platform with governance, sequencing, and ownership designed before the first application ships.
Portfolio order is decided by consequence, not convenience. Three factors determine sequencing: criticality tier, the first-hour consequence a business owner signed; continuity exposure, how badly the application behaves during change; and the nearest end-of-support date, the factor that moves without permission.
Two constraints gate ranking. Shared dependencies mean applications on the same database or integration bus move as a group. Rehearsal capacity is limited team availability for parallel runs and cutover support.
Common Failure Modes
Technology chosen before discovery. The target architecture diagram predates the rules catalogue.
Rebuild recreates old screens. The stack modernizes; the original process compromises are preserved.
Hosting move filed as modernization. Rehosting relocates infrastructure; replatform modernizes the runtime.
Retirement stalls on ownership. The technical work completes but sign-off never arrives.
Cutover underestimated. Parallel running, validation, training, and hypercare are planned last.
Justin Bowen
Sr. Vice President, Delivery Services
Justin has spent more than 15 years at i3solutions and more than 25 years leading project, program, and product delivery across complex technology environments. His work centers on turning strategy into governed execution, aligning technical teams and stakeholders, managing delivery risk, and guiding Microsoft 365, SharePoint, Power Platform, cloud, data, automation, and custom application programs through measurable production outcomes.
Start by adding the sixth path the question leaves out. Retain and remediate, refactor, replatform, rebuild, replace, and retire are the six, ordered by how much of the application survives. Select by four inputs, application health, business criticality, technical debt against dated support windows, and cost and risk shapes, and settle conflicts by ranking dated external constraints above continuity exposure above health-based removals, with cost shape settling what remains.
Recover the rules before choosing a path. The application has become its own specification, so the first work is extraction. Run the system against real cases, read the code paths that fire, and write down each rule beside the person who can confirm it still matches the business. That written rules catalogue is the artifact every remaining decision depends on.
When the implementation blocks changes the business has already asked for, and no smaller path removes the block. Test paths in order: dependency upgrades, platform moves, then refactoring, before committing to a rebuild. Rewrites overrun on undocumented rules, so a rebuild is worth the risk only when the rules catalogue exists and the smaller paths have been priced and rejected.
Produce three records per candidate: sign-in activity across twelve months, downstream systems that consume its data, and business processes that depend on its outputs. Then check for blockers beyond sentiment, statutory retention periods, seasonal users, quarterly integrations, annual audit reports. The archive and sign-off are the actual work; the technical shutdown is small.
The assessment needs three capabilities in the room: someone reading existing code and dependencies, someone with recent delivery experience on the candidate routes, and someone extracting business rules from owners. Recent delivery experience on the remaining candidates is the scarce capability, and it is what separates a defensible recommendation from a plausible one.
The Rebuild Is Cheaper Before the Platform Forces the Date
Failing tools, prototypes in production, and applications past their platform's design space migrate on your schedule or on a deadline an outage picks. i3solutions' senior application architects work with IT leaders ready to scope the build deliberately.
