Every Modernization Decision Needs Evidence the 7 Rs Don't Provide
A bank spent fourteen months deciding what to do with its estate. Workshops, portfolio rationalisation, a scoring matrix with eleven weighted criteria. The plan looked rigorous.
Eighteen months into execution, several re-architecture candidates had been quietly downgraded to retain. Two applications marked for retirement turned out to feed a month-end reconciliation nobody had documented. The replatform track overran badly, almost entirely on database-adjacent code the assessment never looked at.
The framework wasn't wrong. The inputs were.
The 7 Rs classify what you will do to an application. They say nothing about how you decide which one applies — and in a 400-application estate, that decision is the programme. It is also where most downstream rework originates.
This post attempts to give an accurate account of the seven options, then explains the impact of each one at the layer where the money is actually spent: the source code.
Where the 7 Rs Came From
In 2010, Gartner analyst Richard Watson published five migration options for moving applications to the cloud: rehost, refactor, revise, rebuild, replace. The framing was explicitly about cloud adoption.
In 2016, AWS's Stephen Orban restated it as six: rehost, replatform, repurchase, refactor/re-architect, retire, retain. This version stuck, largely because AWS put marketing weight behind it and because "the 6 Rs" was a cleaner mnemonic.
A seventh — relocate — was added later, to describe moving virtualised workloads wholesale (typically VMware estates) without touching the operating system, the application, or the deployment tooling.
So the current day canonical seven are:
| R | What it means |
|---|---|
| Retire | Decommission the application. Stop paying for it. |
| Retain | Leave it where it is, deliberately, and revisit later. |
| Rehost | Move it as-is. Lift and shift. No code change. |
| Relocate | Move the whole virtualised environment. No OS or code change. |
| Repurchase | Replace it with a commercial or SaaS product. |
| Replatform | Move it, and change the platform underneath it — database, app server, runtime — without changing what it does. |
| Refactor / Re-architect | Rewrite meaningful parts of it to change how it is built. |
That table is accurate and it is all the definitional content most readers need. The interesting question starts one layer down.
The Framework's Blind Spot
Every one of the seven is a decision. Each decision requires evidence:
- Retire requires proof that nothing depends on the application.
- Repurchase requires knowing what business logic is embedded in the current system that the replacement product will not cover.
- Replatform requires knowing every place the code touches the platform you are replacing.
- Refactor requires knowing what the application actually does — which, in a system that has absorbed twenty years of regulatory change, is frequently not what anyone believes it does.
The 7 Rs framework provides none of this. It assumes the evidence exists.
In most regulated enterprises, it does not. What exists is a CMDB with drifted entries, an architecture diagram from a previous transformation programme, and three or four people whose tenure predates the last major release.
Some Golden Rules That Always Apply
Before walking each R, the sequencing. This is where the largest, cheapest wins are available, and where the most common ordering errors sit.
1. Retire first, and retire based on evidence
Every application you decommission is one you do not have to assess, move, test, or govern. Retirement is the highest-leverage R and it is consistently done last, because it is politically hard and because nobody can prove the application is unused. Invert this.
Establish dependency evidence at the start of the programme and retire aggressively on the strength of it.
2. Decide repurchase before you decide anything else about the survivors
There is no sense replatforming an application you intend to replace with a product in eighteen months. Yet repurchase decisions frequently get deferred because they involve procurement, vendor evaluation and budget lines that move on a different clock than the migration programme. Pull them forward.
3. Always replatform before you refactor
This is the single most common sequencing error. Teams attempt architectural change and platform change in the same programme, and then cannot attribute a production defect to either. Replatforming is mechanical, testable against existing behaviour, and produces a clean regression baseline. Refactoring on top of a stable, modern platform is a fundamentally easier problem than refactoring and replatforming at once.
4. Rehost only if there is a very strong reason to
Rehosting is legitimate when there is a datacentre exit deadline. It is not a modernization outcome. Estates that rehost without a follow-on plan end up with the same technical debt, now billed hourly.
5. Retain with an expiry date and a comprehension plan
"Retain" too often means "forget." A retained application still ages, still loses the people who understand it, and is still in scope when the regulator asks how a calculation is performed.
The Seven, Read at the Code Layer
Each option below is treated the same way:
- What it means at the infrastructure layer,
- What it demands at the code layer,
- What role Vyazen does and does not play.
Retire
Infrastructure layer: Switch it off, reclaim the licences and the capacity.
Code layer: the question is not "is anyone using it" — usage telemetry catches the obvious cases. The question is what else calls into it. Batch jobs, scheduled reconciliations, reporting extracts, a stored procedure in a shared schema, an integration that fires four times a year at quarter close. These are the dependencies that do not appear in traffic monitoring and do not appear in any diagram.
Where Vyazen plays: this is a code-graph problem. Building a semantic dependency map across the estate — including database-level and integration-level edges, not just service calls — converts retirement from a political argument into an evidence-backed one. Dead-path identification within surviving applications falls out of the same analysis.
Vyazen Role: Important role to play in deciding the retirement decision.
Retain
Infrastructure layer: No action.
Code layer: a retained application is a comprehension liability with a clock on it. The people who understand it retire, resign, or move on. In three years the retain decision has quietly become a rebuild decision, at ten times the cost.
Where Vyazen plays: indirectly but usefully. Maintaining a current, queryable semantic model of retained applications preserves institutional comprehension independent of headcount. It does not modernize anything. It stops the retain decision from silently degrading.
Vyazen Role: Narrow role as no change is made.
Rehost
Infrastructure layer: lift and shift. This is well-tooled and largely solved.
Code layer: rehosting is supposed to require no code change, and mostly it does not. The exceptions are assumptions baked into source: hardcoded paths, hostname and IP literals, filesystem expectations, timezone and locale assumptions, endpoints pointing at things that will not exist at the destination.
Where Vyazen plays: pre-flight surfacing of environment-coupled code. Useful, but modest — this is a checklist that code analysis can complete faster and more completely than a human sweep. The move itself is not a Vyazen problem.
Vyazen Role: Narrow role as the change is primarily an infrastructure decision.
Relocate
Infrastructure layer: move the virtualised estate. Hypervisor to hypervisor.
Code layer: nothing. That is the entire point of relocate. No OS change, no application change, no code touched.
Where Vyazen plays: nowhere. If your programme is a relocate programme, there is no code-layer engagement to have. We say this because the credibility of the three claims above and below depends on not stretching.
Vyazen Role: Narrow role as the change is primarily an infrastructure decision.
Repurchase
Infrastructure layer: buy the product, migrate the data, decommission the old system.
Code layer: the risk in repurchase is never the product. It is the twenty years of accreted logic sitting in the system being replaced — the exception handling for a specific regulator's format, the workaround for a partner's non-conformant API, the rounding convention that a downstream system depends on. Fit-gap analyses conducted from user interviews find the business processes people remember. They miss the logic nobody remembers because it was written to handle an edge case in 2009.
Where Vyazen plays: extracting the behavioural surface — what the system actually does, what it integrates with, where the non-standard logic lives — so the fit-gap analysis is grounded in code rather than recollection. This materially improves the buy/build decision. It does not implement the SaaS.
Vyazen Role: Significant role to validate the behaviour of the current application with the new application.
Replatform
Infrastructure layer: same application, different platform underneath.
Code layer: this is where the work actually is, and it is systematically underestimated. In BFSI the common replatforms are consistent:
- Oracle to PostgreSQL — PL/SQL to PL/pgSQL, packages, hierarchical queries, sequences, DUAL, Oracle-specific date and NULL handling, and every application-layer query that assumed Oracle semantics. The database migration tooling handles schema and data. The application code is the long pole.
- WebSphere / WebLogic to open-source app servers — vendor-specific deployment descriptors, proprietary JNDI, container-managed behaviour the application quietly relies on.
- Runtime and version upgrades — JDK, MySQL major-version upgrades, framework versions with removed APIs and changed defaults.
Where Vyazen plays: this is the core wedge. Semantic analysis identifies every code path coupled to the platform being replaced — not by pattern-matching strings, but by understanding what the code does. Transformation runs through a phase-gated pipeline where each change is reviewed, tested against existing behaviour, and traceable. Replatforming is high-volume, mechanically repetitive, and behaviourally constrained. That combination is exactly what governed agentic delivery is good at.
Vyazen Role: This is the core capability of Vyazen to help modernize the code.
Refactor / Re-architect — Vyazen posture: decisive
Infrastructure layer: largely irrelevant. This is an application-layer decision.
Code layer: the highest cost, the highest failure rate, and the weakest governance of the seven. Monolith decomposition, service extraction, replacing a data access layer, restructuring a domain model. The failure is rarely technical capability. It is that the target state was designed against an understanding of the current system that was incomplete.
Where Vyazen plays: two things. Establishing what the system actually does before the target architecture is designed — behavioural extraction rather than architectural aspiration. And executing the change through a governed, phase-gated pipeline with an auditable trace for every modification.
Vyazen Role: This is the core capability of Vyazen to help modernize the code.
Why the Code Context Matters More in Regulated Enterprises
There is a category of tooling that will make changes to your codebase autonomously and quickly. For a startup shipping a greenfield product, that is a reasonable trade.
For a bank, it is not. A regulated enterprise cannot deploy a change it cannot explain. When the RBI's IT examination asks how a specific control is implemented, "an agent modified it" is not an answer. Neither is a diff with no rationale attached.
Vyazen Continuum is built around that constraint rather than in spite of it. Phase gates, human review at defined checkpoints, and a complete trace from requirement to merged change are not overhead bolted onto an autonomous system. They are the reason the output is deployable in an estate where someone will eventually ask you to justify it.