Application Modernization Decision Framework: Six Paths

Application Modernization: Rebuild, Replatform, Refactor, Replace, or Retire? An Enterprise Decision Framework

By Michael Branson | September 7, 2026

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.

The people who arrive at this question are not shopping for a platform. A CIO has an application the business runs on and a vendor notice with a date on it. An IT director inherited a system whose developer resigned three years ago, leaving no design document. An enterprise architect has forty applications and budget for four. A portfolio owner has been asked which systems can be switched off and holds no record.

This page is written for that room. The title above names the five moves that change the application, and the framework adds retain and remediate as the sixth. What follows is those six paths, the four inputs that pick one, the order they take when they collide, the order a portfolio moves in, and the artifact behind each verdict.

What This Page Decides, and What It Hands Off

Two questions get settled here: which of the six paths fits a specific application, and which applications move first. Nothing else. Engagement structure, delivery method, and platform selection each belong to a page that owns them, and settling all of it in one meeting is how a program becomes a nine-month procurement.

Engagement structure is the first hand-off. What an engagement delivers, how it is governed, and how it closes sit on the Microsoft Modernization Consulting page, linked below where this page sets out what a decision hands back.

Delivery capability, moving legacy systems while the business that depends on them keeps running, is set out at Modernize Legacy Systems without Disrupting the Enterprise. This page picks the path. That page runs it, and its methodology is not restated here.

Whether a rewrite is worth the risk once the person who built the system has gone is answered at When to Rewrite Legacy Code After the Developer Leaves. Rewrite risk appears below at framework depth and no deeper.

Three further hand-offs fire only after a path is chosen. Where replace is the verdict and the candidate is a low-code product, the platform question is worked at Power Apps vs. Custom .NET: Decision Guide. Where the legacy artifact is a forms estate, the mechanics live at InfoPath Migration Services for Enterprise Microsoft Environments. Where a program has already started and stopped, the route is How to Rescue a Stalled or Failed Microsoft Modernization.

Spreadsheet-based processes have their own modernization decision elsewhere, and the method for turning one into an application is out of scope here.

What remains is the decision: six paths, four inputs, a rule for what happens when they disagree, and a portfolio order that survives the risk argument this page makes.

The Six Application Modernization Paths, Ordered by How Much Survives

A path is a verdict about one application rather than a policy for a portfolio. The order below runs from least change to most. The argument in the room starts at rebuild and works outward, which is how the two cheapest verdicts get skipped.

Microsoft publishes a vocabulary of its own, The 6 Rs of application modernization. That page names its strategies Rehost, Replatform, Refactor, Rebuild, Retire, and Retain, and says they build on the popular 5 Rs used to rationalize cloud migration. Two differences matter when a cloud team and an application team argue from separate lists. Microsoft’s list carries Rehost, which this framework treats as an infrastructure move rather than a verdict. Microsoft’s list names no replace strategy, and this framework adds one, because a packaged or low-code product meeting the requirement is an outcome a portfolio owner weighs against a build. Retain sits on both lists in the same shape, bounded there to organizations not ready to modernize because of cost, dependencies, risks, or other factors.

Path	What it is	When it wins	What it costs you	First test, an artifact you can produce
Retain and remediate	Keep the application and repair the support, security, and ownership gaps around it	Business fit is intact and the failures are operational rather than structural	Defers structural change, so somebody has to date the deferral	A support statement listing each unpatched component, its owner, and the date it leaves vendor support
Refactor	Improve the code and structure in place, without changing what the application does for users	The architecture holds, the code is understood, and the debt is local	Pays for work no user can see, which makes it the hardest path to fund	A dependency inventory marking each component supported, unsupported, or unknown, with a named owner on the unknowns
Replatform	Modernize the runtime and platform the application itself depends on, updating framework, hosting, and configuration with limited functional redesign	The application earns its keep and the stack beneath it has aged out of support	Carries process and data debt across intact onto the new platform	A hosting and configuration inventory naming what runs the application today and what a candidate platform must reproduce
Rebuild	Build the capability again on a current stack, keeping the business rules and discarding the implementation	The requirement is real and the implementation blocks the changes the business now asks for	Rebuilds rules nobody wrote down, so discovery is the schedule risk	A written rules catalogue extracted from the running system, with unsourced rules logged as open items against a named owner
Replace	Meet the requirement with a packaged product or a low-code application instead of custom code	The process sits close to a market standard and differentiation lives elsewhere	Trades control for a vendor roadmap, and 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 what it still does	Usage has collapsed, or another system already holds the capability	Somebody loses a report, so the archive and the sign-off are the actual work	A usage and data record: who signed in across twelve months, which reports read from it, and where the data lands

Two of those six rows get decided by avoidance. Retire loses to sentiment when an application with four sign-ins in a year survives because nobody has asked the person who would sign the archive off. Retirement is also blocked by things that are not sentiment: a statutory retention period, a report read once a year at audit, a batch integration that fires quarterly, or a seasonal user population. Replace loses to fear of a fit gap, which is a cost to price rather than a mood, and lock-in, exit cost, and data residency price alongside it. That gap list comes back quickly where the process is a commodity one and the vendor hands you a working configuration, and it takes as long as integration testing, licensing review, and workflow validation take where those are in scope.

The closest lived proof this framework has is one engagement shape. A services firm running a cloud migration decided each customization separately rather than as a program: some replaced by standard capability, some retired outright, some reengineered because the requirement behind them was real.

The column that decides the most is the last one. A path chosen without its first test is a preference with a vocabulary; a path chosen with the artifact in hand is defensible to a board.

Application Health and Who Can Still Change the Code

The first input is health, measured on two axes at once: what the code can still do, and what your organization can still do to the code.

Start with the second axis. The developer left is the sentence that opens the conversation, and it carries more than a staffing gap. It means the business rules live in the implementation and nowhere else, the build process is undocumented, and the person who knew why a routine exists now works elsewhere.

Grade that with three questions that have factual answers. When was the last change deployed, and by whom? Can anyone on the team rebuild the application from source today, on a machine that has never built it? Does a change estimate come from reading the code or from guessing? Three weak answers describe a frozen application, already on a path whether or not anyone has named it.

The code axis has one clean signal, patchability. A legacy application whose runtime, framework, or third-party components can still take a security update sits in a different category from one where the patch is blocked. We cannot patch it anymore is a statement about the dependency chain, and it is verifiable: name the component, name the version, name the date its support ended, and name what breaks if it moves.

Microsoft’s upgrade guidance names the same trigger in the same terms, that upgrading is worth considering when .NET or other dependencies reach end of support. The Overview of upgrading .NET apps states the bound in the same passage: on the .NET Framework route the app model, project format, and some APIs change, and technologies unavailable in modern .NET have to be replaced.

Test app-model portability as its own question, because a clean dependency list does not settle it. Web Forms, WCF, COM interop, and Windows-only APIs each block a move the dependency inventory calls straightforward, and each is found by building against the target rather than by reading a version table.

Health removes paths rather than selecting one, which is more useful. An application nobody can safely change removes refactor, because refactoring assumes comprehension. A dependency chain with no supported upgrade route removes retain and remediate past a fixed horizon.

Business Criticality and Business Continuity

The second input is what the business loses when the application is unavailable. Rank criticality by consequence in the first hour, the first day, and the first week: revenue that stops, an obligation unmet, a customer commitment that fails, staff who go idle. Write it as a sentence a business owner will sign, because a tier assigned by IT alone gets renegotiated during the outage.

Business continuity is the second measurement, and it asks a different question from criticality: what the business does during the change rather than what it loses if the application stops. One application tolerates a weekend cutover with a parallel run behind it. Another, at identical criticality, has a regulatory clock running through the cutover window and no rehearsed fallback.

Where an application has no room to stop, the work changes shape before the path does. Microsoft documents the pattern that fits, the Strangler Fig pattern: functionality moves piece by piece to new applications and services until the old system is decommissioned. The mechanism is a facade, a proxy that intercepts requests going to the legacy system and routes each one to the old side or the new. Carry the limit stated in the same guidance: that facade is transitional architecture whose risk mitigation is balanced against a temporary infrastructure cost.

That makes a missing seam a price rather than a verdict. Where service boundaries exist, rebuild and replace stop being all-or-nothing bets. Where they do not, a seam can be built: routing through a facade, branching behind an abstraction, intercepting events, or standing up a reporting replica. That enabling work is a line item with a schedule and a cost. Treating an absent seam as an automatic retain and remediate hides the cost inside a deferral that still carries a date.

Continuity also prices the paths. A parallel run costs staff time on both systems, and a phased cutover costs integration work that exists only during the transition. Neither appears in a development estimate.

If two of these signals are firing on an application you own, the useful next step is a reading of your own numbers rather than another opinion. That conversation can end with keeping the application and remediating it, and it can end with i3solutions saying the work belongs somewhere other than here. Both answers are usable, which is the point of having it early. Talk to a senior architect

Technical Debt and the End-of-Support Date

The third input gets talked about most and measured least. Technical debt is a rate, not a quantity, and the rate is what gets priced. The question is how much slower each change gets, and how much capacity goes on holding the position rather than moving it.

Three numbers make the rate visible, and they do not come from the same place. Change lead time against the median for comparable systems is queryable from ticket and deployment history you already keep. The share of engineering hours spent on defects and workarounds has to be reconstructed in most estates, because hours are rarely allocated per application. A sprint-by-sprint reading of what the team worked on is close enough to argue from, labeled as a reconstruction. The count of changes requested and then withdrawn because the estimate was too high is recorded nowhere; it comes from asking business owners what they stopped asking for.

End-of-support dates are different in kind. Every other input here is a judgment with a range. A vendor support date is a fact with a calendar entry, published outside your organization, and it turns a strategic discussion into a scheduling problem. Build the dated list where dates exist: operating system, runtime, framework, database engine, commercial components, and the integration endpoints being retired.

Part of that list will not have dates. An open-source library whose last commit is four years old, a package whose maintainer stopped answering, and a hosted API on a rolling deprecation notice each carry exposure with no calendar entry. Those become named risk items in the same list, each with an owner and a review date you set. A list that silently drops them reports a cleaner estate than you have.

Tooling covers part of the inventory, inside stated bounds. Microsoft’s .NET migration cases for Azure App Service describes at-scale, agentless discovery and assessment of ASP.NET web apps, returning readiness, migration blockers, remediation guidance, and hosting costs. The bound sits in the same passage and it is narrow: that route discovers ASP.NET web apps running on Internet Information Services servers in a VMware environment. Outside those bounds the estate is not reduced to a manual trawl. The same page names PowerShell scripts that discover and assess all IIS web apps on a single server in bulk, and a migration assistant for .NET web apps on Windows. Configuration databases and endpoint inventories each return a further slice. Run whichever routes reach your estate, record what each one missed, and treat the union as the inventory.

Debt and dates interact in one direction. Debt argues for refactor while the code is still understood, and a support date removes that option by arriving first. An application that would have been a clean refactor two years ago becomes a replatform under a deadline, then a rebuild once the deadline passes.

Cost Shape and Risk Shape

The fourth input is cost and risk, and this page carries no prices. Shape is what makes two options comparable while the numbers are still estimates.

Cost shape has three components per path. The one-time build or move, which is an estimate. The recurring run cost: hosting, licensing, support, and the engineering capacity the application consumes each year. The cost of the deferral, the current run cost plus the remediation that keeps it defensible. The third gets omitted, which makes retain and remediate look free.

Fix the horizon before comparing anything, because curve shapes cross at different points. These shapes are tendencies rather than laws, and each hides a category the first estimate leaves out. Rebuild front-loads spend, then falls to a run cost that holds flat only while the new stack stays current. Retain and remediate looks flat and steps up ahead of each support date rather than on it. Replace converts capital spend into a subscription tracking headcount and a roadmap you do not control. Name what each estimate omits: integration rework on replace, data migration on rebuild, exit cost on both.

Risk shape splits into two families that get confused. Delivery risk is that the work costs more or takes longer than planned. Continuity risk is that the business is harmed during the change. They call for opposite responses: delivery risk is answered by cutting scope early, continuity risk by parallel running and rehearsal, which adds scope. A plan treating them as one number pays in the other.

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, so the discovery that should have preceded the build happens during it. Rewrite risk is discovery risk, bounded by an artifact: the rules catalogue named in the framework table.

Microsoft’s cloud adoption guidance puts the same ordering ahead of the technical work, defining motivations, mission, and objectives before the decisions measured against them. See Determine your motivations, mission, and objectives. Carry the limit: it collects objectives at program level for a cloud adoption strategy, so it frames the portfolio conversation without settling a verdict on one application.

The four inputs collide, and the order between them is fixed rather than negotiated. A dated external constraint dominates: a support date, a regulatory deadline, or a vendor end-of-life notice sets the horizon everything else is planned inside. Continuity exposure comes second, because a path the business cannot survive during the change is not a candidate whatever its cost curve looks like. Health-based removals come third, since a path assuming comprehension nobody has is off the list before the business case is written. Cost shape breaks the tie.

Which Applications Move First

Portfolio order is a separate decision from path selection, and it is where a defensible framework gets abandoned under pressure. The instinct is to start with the easiest application, the loudest sponsor, or the largest user base. Each of those orders defers a risk this page has already named.

Size the order by consequence instead. Three factors set it, and each is documented already if the four inputs were worked. Criticality tier, from the first-hour consequence a business owner signed. Continuity exposure, how badly the application behaves during a change and how little room there is to rehearse. The nearest end-of-support date in its dependency list, the one factor that moves without your permission.

Two constraints gate the ranking before any of that applies. Shared dependencies come first: applications sitting on the same database, integration bus, or identity configuration move as a group, because moving one changes the ground under the others. Rehearsal capacity comes second: the people who can run a parallel run, validate migrated data, and staff a hypercare window are a fixed number. An order that puts two continuity-heavy cutovers in the same month has booked the same team twice. Procurement lead time sits inside both.

Test any proposed order against the risks the framework produced. An order that leaves the unpatchable application until the fourth quarter defers the structural risk while working on comfortable ones. An order that starts with a low-criticality system because it is easy buys a fast result and no reduction in exposure. An order that puts a high-continuity-risk application first, with no rehearsal capacity, converts a scheduling problem into an outage.

Two ordering rules survive that test. Move first where the consequence of doing nothing is dated and external, because those dates set themselves. Move second where continuity exposure is high and the remediation is understood, and only once rehearsal capacity exists rather than being promised. A small, low-risk application taken early is a legitimate exception when it is scheduled as a rehearsal, with a named lesson to prove.

Retirement candidates belong in the same order rather than in a cleanup phase that never gets funded. A retirement candidate consumes support, licensing, and audit attention every month it stays alive, and the sign-off takes longer than the technical work. Open the ownership conversation at portfolio triage, in the same pass that assigns criticality tiers.

If the order is what is being argued internally, that argument is a good use of an outside conversation. Bring the application inventory with its unknowns marked, the support dates you hold, and the two systems your operations lead would escalate first. What comes back is a written order with the reasoning attached, in a form you can circulate. It can say retain and remediate at the top of the list, and it can say this is not our work. Talk to a senior architect

Common Failure Modes

Five patterns account for the stalls in this decision, and each has an early tell.

Technology gets chosen before discovery. A platform is selected in a leadership meeting, and the discovery that follows is scoped to justify it. The tell is a target architecture diagram that predates the rules catalogue. Discovery run after the decision finds confirmation, not evidence.

The rebuild recreates the old screens. A rebuild that reproduces the existing interface, field by field, buys a modern stack and keeps every process compromise baked into the original. Look for a requirements document written by reading the current application rather than by watching the work it supports.

A hosting move is filed as modernization. Rehosting relocates the application onto different infrastructure. It changes the operational profile and leaves the runtime, the framework, and the maintainability problem where they were. Replatform is a different move, and the difference is what the application depends on: replatform modernizes the runtime and platform underneath it, which is how it retires a dependency instead of relocating one. Rehosting is a legitimate step and it is not a verdict about the application. The giveaway is a charter whose success measure is applications moved rather than risk retired.

Retirement stalls on ownership. The evidence for retiring an application is usually assembled quickly. The sign-off is not, because nobody wants to be the person who agreed to switch off the system somebody later needed. Watch for a candidate that has sat on the list three quarters running with the technical work complete.

Cutover is underestimated. Parallel running, data validation, training, hypercare, and the support model after go-live carry real cost and get planned last. The signal is a plan where go-live and the end of the project are the same date.

How i3solutions Runs the Application Modernization Decision

What comes back from this decision is a record rather than a proposal, and its shape is worth knowing before you ask for one.

Four evidence artifacts arrive, each a document your own team can check. A dependency inventory marking every component supported, unsupported, or unknown, with an owner named against each unknown and undated dependencies carried as risks. A rules catalogue extracted from the running system, with the rules nobody can confirm logged as open items rather than assumptions. A criticality and continuity statement written in consequences a business owner signs. A dated support list. Those four are the four inputs above, answered against your evidence.

The verdict is written per application rather than per portfolio, with the artifact behind each one attached. Forty applications come back as forty verdicts and one order, because a single direction across a mixed estate is what this framework exists to prevent.

Three endings are available, each a real result rather than a stage on the way to a sale. The verdict can read retain and remediate, with a dated remediation plan and the date the deferral expires. It can read that the work is ours, in which case what you hold is a decision record and a build path. It can read that the work belongs to somebody else.

How an engagement is structured around those outputs, what it delivers, and how it is governed sit with Microsoft Modernization Consulting, the page to read once the verdict is settled.

The record behind the verdict is a bench of Microsoft application work. It includes a member-services application replatformed to .NET for a national trade association and process-automation applications built in .NET for a senior-living organization. It also includes a legacy forms estate replaced with Power Apps for a state military organization and an intranet modernization for a federal agency. Those are engagement shapes rather than named case studies, and the wider record sits at Explore Our Work.

i3solutions has been a Microsoft partner since 1997 and has delivered 600+ Microsoft platform implementations. What that buys a portfolio owner is borrowed expertise: pattern recognition from applications that reached this decision before yours did, applied to your evidence before a direction is committed. Delivery that follows a verdict runs under Enterprise Delivery Assurance, the discipline named for landing work on-time, in-scope, and in-production.

When i3solutions Is Not the Right Next Call

Four situations belong somewhere else, and naming them saves a scoping call on both sides.

The decision is already made and what you need is hands. If the path is settled, the rules are documented, and the constraint is delivery capacity, that is a staffing conversation and deserves to be scoped and priced as one rather than dressed up as an assessment.

The requirement is a commodity package selection. Where the process is standard, the market has three credible products, and the real work is procurement and change management, an architecture opinion adds a month and little else. Run the selection with the people who will operate it.

The estate is not a Microsoft estate. This framework transfers to other technology stacks, and our delivery bench does not. If the application is a mainframe workload or runs on a stack we do not build in, a firm working in that stack will serve you better on everything after the verdict.

The blocker is organizational rather than technical. Where two business units disagree about who owns the process the application encodes, no modernization path resolves that, and starting the technical work first buries the disagreement inside a project that will then fail for reasons nobody records.

What is left is the case this page was written for: an application that matters, evidence that is incomplete, and a decision that carries a date somebody else set. Bring what you have, including the gaps. The four inputs above get worked against your own records, and the output is a written verdict per application with the artifact behind it attached. Three endings are honest here. You keep the application and remediate it on a dated plan. Or the work is ours, and you leave with a decision record and a build path instead of a proposal. Or it belongs to somebody else, and we would rather say that in the first conversation than in the third month. Talk to a senior architect

Frequently Asked Questions

Rebuild, replatform, refactor, replace, or retire, how do we choose?

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, and the first is a legitimate verdict rather than a failure to decide. Four inputs pick one. Application health, including whether anyone can still change the code safely. Business criticality and what continuity requires during the change. Technical debt measured against the dates your dependencies leave support. Cost shape and risk shape across a fixed horizon. Each input produces an artifact rather than an opinion. When the inputs disagree, a dated external constraint outranks continuity exposure, continuity outranks the removals health makes, and cost shape settles what is left.

How do we modernize a legacy application when the original developer is gone?

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. Rules nobody can confirm become open items with a named owner rather than assumptions. That catalogue is what makes rebuild, replace, and refactor comparable, because each is then priced against the same list. Without it, every estimate is a guess wearing a number, and the discovery that should have happened first happens during the build.

When is rewriting an application worth the risk?

When the implementation blocks changes the business has already asked for, and no smaller path removes the block. Test that in order. If a dependency upgrade restores patchability, take it. If a platform move fixes the operational failures, take that instead. If the code is comprehensible and the debt is local, refactor. A rewrite earns its risk when those three have been worked on paper and none reaches the problem. That is a structural fact rather than a matter of taste: the data model, the coupling, or a runtime with no supported upgrade route. Then size the risk correctly. Rewrite risk is discovery risk rather than coding risk, and it is bounded by the quality of the rules catalogue you produce before committing.

How do we decide which legacy applications to retire?

Retirement is an evidence decision with an owner attached. Produce three records per candidate: who signed in across the last twelve months, which reports and downstream systems consume its data, and which business process still depends on an output it produces. A system with negligible sign-ins, no downstream reader, and a capability another application already holds is a retire candidate on the record rather than on opinion. Then check the blockers that are not sentiment: a statutory retention period on the data, a user population that appears only in a season, a report read once a year at audit, or a batch integration that fires quarterly. Each is a condition to price and schedule rather than a reason to leave the candidate untouched. Name the person who signs the archive off, and decide where the data lives afterwards and for how long.

Who can assess a legacy Microsoft application for modernization?

The assessment needs three capabilities in the same room. Somebody who reads the existing code and its dependency chain. Somebody who has delivered recently on the candidate implementation routes still in play, recently enough to price them. Somebody who can sit with a business owner and extract rules without a manual. Internal architecture teams commonly hold the first and the third, with the caveat that a team which has not opened this application’s source in years starts where an outsider starts. The scarce capability is recent delivery experience on the routes that are still candidates, and that is what turns an assessment into a costed decision.