Retire and Retain: the two often-overlooked migration strategies When people talk about cloud migration, they generally imagine that everything must move to AWS. That is a costly mistake. Two of the six transformation models, Retire and Retain, are paradoxically the most cost-effective and the fastest to implement, but also the most poorly assessed during the assessment phase.
Retire means shutting the application down. Retain means keeping it on-premise, or at least not migrating it right now. Neither one produces a flashy investment line item. Yet shutting down an obsolete application reduces technical debt, frees up resources, and simplifies the IT portfolio. Keeping a critical but tightly infrastructure-bound application on-premise avoids a costly and risky migration, while freeing budget for the real cloud gains.
It is precisely on these two decisions that teams drag their feet. They fear missing out on value, upsetting a business unit, or they simply do not know where to start when assessing whether an application truly deserves a migration ticket. The 6R framework helps you decide.
Retire: when shutting down an application costs less than maintaining it An application is a Retire candidate as soon as it meets at least one of these criteria: it no longer has regular active users, it generates little or no business value, it fulfills a function duplicated by another system, or its maintenance and licensing cost exceeds its quantifiable benefit.
The confusion often comes from the fact that a "historically important" application stays in the portfolio out of habit. People keep maintaining it, patching it, training the few remaining users, without asking whether it still generates revenue. Worse, a cloud migration forces the IT team to relaunch it, transform it, and invest heavily in it, when it could have been retired for almost nothing.
To identify Retire candidates, start with usage: who actually uses it, and how many times per month? If the number is below, say, a few dozen monthly transactions, or if the function is already covered by another modern tool (ERP, SaaS platform, etc.), the migration makes no sense. Move on to a simple cost-benefit analysis: divide the total annual cost of maintenance, licensing, infrastructure, and support by the quantified benefit (revenue supported, savings, productivity). If the ratio is below 0.1 or 0.2, the application exists only through inertia.
Retire also carries a hidden benefit: reducing the security surface, simplifying compliance (fewer systems to audit), and lowering the complexity of the IT portfolio. A team that manages 20 critical applications is more productive than one that manages 50, half of which are dormant. So before signing a migration quote, purge that backlog.
Retain: the applications that must stay on-premise today Retain is the opposite choice. The application has value and active users, but migrating it would cost too much, take too long, or cement dependencies on the on-premise infrastructure that there is no time to untangle before the migration.
Classic Retain candidates include legacy monoliths tightly interwoven with the local infrastructure, specialized database systems (proprietary databases, appliances with physical hardware), applications that depend on very low-latency network integrations, and systems that require specific certificates or hardware configurations that are hard to reproduce in the cloud.
Another relevant category for Retain: applications whose migration is technically possible but whose ROI is too low. For example, a critical yet stable application, consuming few resources, with few users and little maintenance. Migrating such an application easily costs three to six times more than it is worth. Economic rationality then dictates leaving it in place. The on-premise infrastructure ends up being a museum of these applications, which is normal: the goal of the cloud is not to move everything that exists, but to realign the IT portfolio with real business value.
Retain can also be a temporary choice. A complex application can stay on-premise today, waiting for a lighter future version that can be migrated, or waiting for the technical debt to be paid down internally before considering a cloud transformation. This approach reduces risk: rather than forcing a migration at all costs within an 18-month schedule, you let the infrastructure team focus on immediate gains and revisit Retain in a year.
Concrete criteria for deciding between Retire and Retain To keep the decision from being subjective, apply a minimal grid. Here are the questions to ask for each candidate application: 1. Who uses it, and how many times per month? If it is fewer than 50 monthly transactions or a few dozen users, it leans toward Retire or a very conservative Retain. 2. What is the total annual cost, infrastructure plus maintenance plus licensing, divided by the revenue supported or the savings generated?If the ratio is above 1 (cost > benefit), that is a Retire signal. If the ratio is between 0.5 and 1, it is Retain pending optimization, or Retire if the technical debt is too high. 3. What are its dependencies with other applications? If it depends on a dozen other systems to function, or if a dozen others depend on it, migrating it becomes a complex undertaking. Retain becomes the smarter choice, unless those dependencies are themselves moving to the cloud (in which case untangle the integrations first). 4. What is the estimated effort to migrate it, in person-days? As a rule of thumb, if it requires more than 50 to 100 days for a Rehost (the simplest migration), it is a Retain candidate, at least temporarily, unless the business benefit is strategic. 5. Is there a SaaS alternative or a cloud-native version of the same tool? If so, Repurchase or Refactor becomes attractive, and Retire of the old version follows naturally. If not, Retain is the logical choice. 6. What is the business risk of shutting it down or leaving it in place? A critical system that tolerates no discontinuity must be Retain, at least for a few months. A "nice to have" application can be Retire without exposing the business.
This assessment does not require a three-month cloud assessment. It requires a three-hour meeting with the business owner, IT ops, and an architect. The result: a list purged of thirty to fifty percent of the applications.
Retire and Retain within the 6R matrix The 6R framework classifies each application according to the type of transformation best suited to it. Retire and Retain are fully part of it, on the same footing as Rehost, Replatform, Refactor, or Repurchase. This classification is not a minute-by-minute action plan; it is a strategic decision that must be made in the first two to three weeks of a cloud assessment.
The 6R matrix (or the 6R Selection Matrix as Stralya offers it) brings together the evaluation criteria: the technical complexity of the application, business value, dependencies, estimated migration cost, implementation duration, and business risk. Retire and Retain are generally located at the two extremes: Retire appears when value is very low and shutting down poses no risk; Retain appears when value is high but complexity or dependencies make migration too costly for the moment.
This classification does not mean Retire or Retain forever. It is a snapshot at a given moment. An application that is Retain today can shift to Rehost in two years, once the dependencies have been untangled or a cloud-native version of the same function becomes available. A Retire application can be reclaimed by the business if the need changes. The value of the 6R matrix is in making these decisions explicit and revisable, and above all in distinguishing the migrations that make sense from those that do not.
Integrating Retire and Retain into the migration plan Once you have classified your applications into Retire, Retain, and the others, the execution phase becomes clear. Retire candidates disappear from the roadmap: they are simply shut down according to a decommissioning schedule (generally a few weeks to a few months to collect audit data, notify users, etc.). This shutdown reduces the overall cost of the migration project and frees up human resources and team cycles.
Retain applications stay in place. They consume no migration budget, but they call for a long-term decision: do you keep maintaining them on-premise in a legacy infrastructure, or do you create a lightweight "Retain islands" strategy, grouping your Retain applications on a minimal and secure infrastructure? Some organizations choose to leave Retain applications as they are; others consolidate them onto a subset of servers or migrate them to a virtualized and slimmed-down on-premise infrastructure, thereby freeing up most of the legacy infrastructure for shutdown.
The discipline to maintain: Retain applications must never become a catch-all for inaction. An annual or biennial review must assess whether the initial assumptions still hold. If a Retain application has seen its user load explode, perhaps migrating part of the traffic to the cloud is worth it. If the business asks for a capacity increase for a Retain application, ask yourself whether you would not gain in agility and cost by migrating it rather than reinforcing the on-premise infrastructure.
For Retire applications, tracking is simple: they disappear on date X. After that date, the IT team no longer talks about them. It is a net gain in complexity and maintenance cost.
Pitfalls to avoid with Retire and Retain The first pitfall is decision paralysis. Organizations accumulate applications over the years, and the idea of shutting one down triggers emotional objections ("but that was a project we funded ten years ago") or organizational ones ("that team still needs it in case the other system fails"). Set yourself a simple rule: if usage is below X and the business does not depend on it directly, shut it down before the end of the migration project. After-the-fact objections are very rare when the application really no longer exists.
The second pitfall is keeping an application in Retain because of exaggerated technical fears. The IT team says, "migrating it would be too complicated, it is too integrated," without having concretely studied the effort. A few days of careful assessment can show that a Rehost is actually within reach, and that once migrated, the application consumes fewer resources and costs less. Invest 10 days of study before deciding Retain, not zero.
The third pitfall: letting Retain applications multiply, become a silent majority, and end up weighing as much as the entire legacy infrastructure. Define an acceptable ceiling (for example, a maximum of 20% of the portfolio in Retain), and review it every year. The applications that remain must have a precise, time-bound justification.
The fourth pitfall is forgetting that Retire creates a need for archiving and compliance. Before shutting down an application, make sure that all historical data that could be useful for legal, tax, or audit purposes is exported and stored somewhere. A poorly prepared shutdown can create regulatory problems months or years later.