Why a 6R selection matrix rather than case-by-case decisions Most cloud migrations begin with a challenge: choosing the right 6R strategy for each application within a portfolio often made up of dozens or hundreds of heterogeneous applications. Without a structured framework, these decisions drag on in steering committees, each participant brandishing conflicting arguments ("it is too critical for a refactor," "SaaS costs too much," "we cannot leave it on-premise"). Months go by, the cost of inaction climbs, and the migration finally starts without any real technical consensus.
A 6R selection matrix solves this problem by imposing a shared logic. It crosses two or three decisive axes (the technical complexity of the app, business value, dependencies, current maintenance cost) and produces an immediate recommendation: not the "best" strategy in absolute terms, but the one best suited to the specific profile of that application and to the urgency of your migration context. It does not replace business judgment, but it frames it and accelerates it. Rather than debating for two weeks whether a given legacy application should be replatformed or refactored, the matrix steers the debate: "according to our parameters, it is a refactor; who objects, and why?"
For a scale-up or a mid-market company grappling with a runaway AWS bill or a heterogeneous technical architecture, this matrix becomes a first-order governance tool. It helps the CTO and their team build a coherent roadmap in days rather than weeks, adapt it as new applications are assessed, and justify to the business why a given application will be migrated in a particular way.
The two main axes: technical complexity and business value Every effective 6R selection matrix rests on two major dimensions that, on their own, cover 80% of real decisions.
The first axis is the technical complexity of the application. A complex application has characteristics such as: a tightly coupled monolithic architecture, multiple dependencies on other systems or on-premise hardware, poorly documented legacy code, a database with millions of queries per day, or critical performance requirements. A simple application, by contrast, is a stateless web app, an isolated business service, a small or medium-sized database, few external dependencies. This technical complexity strongly determines the cost and risk of the migration: a gigantic monolith cannot be exposed to a refactor without breakage. A small business service can handle it without flinching.
The second axis is business value: critical to the functioning of the company (sales, billing, production, quality control), these applications deserve a careful and controlled migration, even if it costs more. Non-critical applications (internal tools, document repositories, old, partially exploited data warehouses) can tolerate a higher risk or a quick rehost, because the impact of an outage is contained.
Crossing these two axes produces four clear quadrants: complex and critical (refactor or rearchitect slowly and rigorously), complex and non-critical (repurchase, or retire if obsolete), simple and critical (replatform carefully, or rehost if there really are few dependencies), simple and non-critical (rehost without hesitation, or retire). This grid is never exhaustive (a third axis such as cost or technical debt is often needed), but it quickly eliminates bad ideas and steers you toward the three or four most relevant 6Rs.
Building your matrix: concrete criteria and key questions A practical 6R matrix does not exist as a universal formula: it must be calibrated to your context. To assemble it, start by listing the criteria that truly discriminate among your applications.
On technical complexity, ask yourself: is this application monolithic or service-oriented? How many external interfaces, database connections, dependencies on other systems? What is the state of the code (well documented, high technical debt, obsolete language)? What are its requirements for performance, latency, concurrency? If a tightly coupled monolith + massive databases + legacy dependencies everywhere = very complex. If a simple REST API + a standard PostgreSQL database = low complexity.
On business value, the classification is often more political than technical: ask the business units themselves which applications cannot be unavailable for even an hour without causing a crisis (sales blocked, billing frozen, production stopped)? Those are critical. The others, even if they are used every day, can tolerate an outage of a few hours.
Add a third criterion if your portfolio calls for it: the current maintenance cost (legacy licensing, on-premise infrastructure cost, internal support effort). A complex but low-maintenance application can be a retire candidate, while a simple but expensive-to-maintain one justifies a SaaS repurchase.
Once your axes are defined, build a simple table: each row = one application, each column = one criterion (complexity: low/medium/high, business value: low/critical, maintenance cost: low/medium/high). You can keep it in a spreadsheet or a cloud portfolio management tool (AWS Migration Evaluator, Cloudscape, etc.). Fill it in collectively: CTO, infrastructure lead, business representative, to avoid a single-voice bias. Then apply your decision rule: if complex + critical = refactor, if simple + low cost = rehost, etc.
Real use cases: applying the matrix to typical profiles Let us take concrete examples to show how the matrix works both for very different applications and for the contexts of fast-growing AWS scale-ups.
First example: a legacy billing application, written in COBOL 20 years ago, at the heart of the information system. Complex: yes (bloated monolith, proprietary database dependencies, few docs, obsolete language). Critical: absolutely (all invoices go through it, an outage means massive damage). Matrix recommendation: refactor or rearchitect. Why? Because you cannot trust a cloud rehost without mastering the code, and you cannot leave it on-premise if its costs are spiraling. So invest a few months in a refactor: modernize progressively into services, test carefully, validate each pass. Or, if the refactor is judged too costly (external dependencies too thick), consider a repurchase to a SaaS billing solution, even if it is more expensive than a rehost: at least you no longer carry the technical debt.
Second example: an internal reporting application, used for business dashboards, written in modern Python, hosted on-premise, low criticality (it can be unavailable for a day without blocking operations). Complex: no (stateless architecture, a few simple SQL queries, well documented, modern language). Matrix recommendation: direct rehost to EC2 or containerization on Lambda. Why? No reason to refactor code that works. A simple, fast migration, with reduced infrastructure costs from the start.
Third example: a small souped-up Excel database, in Access or VBA, used by 3 people to track internal customer orders. Complex: no. Critical: no. Maintenance cost: zero (it is something slapped together late one afternoon). Matrix recommendation: retire or repurchase. Why? Not worth migrating. If the need truly exists, move to a Notion, Airtable, or Google Sheets database, that is to say a near-free SaaS repurchase. Otherwise, stop maintaining it and let this application zombie fade away.
Fourth example: a partial microservices application, modern, written in Node.js and Go, well containerized, but not yet cloud-native (no auto-scaling, no declarative infrastructure management). Complex: moderately (already modern, but ad hoc infrastructure). Critical: yes (it handles the majority of production API requests). Matrix recommendation: replatform to managed Kubernetes (EKS) or refactor for cloud-native (serverless + event-driven where relevant). Why? The application is already partially cloud-ready: moving to a cloud-native infrastructure (managed Kubernetes, IAM, autoscaling) is a thousand times better than a rehost on EC2 that would not address the real scaling problems.
Integrating dependencies and blockers into the matrix A matrix based solely on complexity and business value gives a partial view. Dependencies between applications often transform the recommendations.
Example: you have an application A (billing) that calls an application B (legacy authentication). According to the raw matrix, A = refactor (complex + critical), B = rehost (simple + non-critical, used only by A). But if B is very tightly coupled to A and refactoring it separately costs enormously, you will have to synchronize the two migrations: refactor A and B in parallel or delay one until the other is stabilized in the cloud. This changes the timelines, the risks, the costs.
To integrate dependencies, the matrix must avoid isolated decisions. While filling it in, annotate for each application: "depends on [App X, App Y]" and "is a dependency for [App Z]." Then, before validating the recommendations, trace the migration paths: if app A and app B must be refactored together, merge their trajectories. If app C is retire but app D still depends on it, defer the retire of C until D is ready.
Some AWS migration cohorts use a dependency diagram for this (DAG: directed acyclic graph) before the matrix. It shows which apps form clusters of mutual dependencies. You then handle the matrix cluster by cluster rather than app by app. An isolated cluster can be migrated at its own pace; a critical cluster must be migrated as a block or in a controlled cascade.
This step often reveals hidden blockers: "we thought app X was easy to rehost, but in fact it depends on that old on-premise service we cannot move for 6 months, so the rehost has to wait" or "app Y looks complex to refactor on its own, but if we migrate it at the same time as the overall infrastructure overhaul, it is actually faster." The mechanical matrix then becomes a decision matrix informed by real-world context.
Updating and refining the matrix throughout execution A 6R selection matrix is never set in stone. As you migrate applications, discover hidden dependencies, run into unexpected costs, and receive business feedback, you have to refine it.
In the first weeks of the migration, technical teams often discover that what they thought was "simple" was not (hidden legacy dependencies, a larger database than expected, more tangled code). The initial matrix lets you apply a quick heuristic; execution validates or contradicts that heuristic. When you discover an anomaly ("app X that we thought was a rehost turns out to be complex and requires a refactor"), update the corresponding row, note the reason for the discrepancy, and use that feedback to refine future criteria.
Likewise, some recommendations become obsolete: you had recommended retiring an old app, but in the meantime the business found a new use case. You had chosen a SaaS repurchase, but the vendor raised its prices by 50%. You had bet on a replatform, but the team discovers that refactoring to serverless ultimately costs less. Revising the matrix continuously (quarterly or every two months) keeps decisions consistent and shows the organization that the migration is an adaptive process, not a plan carved in stone.
The matrix thus becomes a living governance artifact: it documents the initial strategy, guides execution, and captures the lessons for future applications. A few companies even publish it on an internal dashboard, with, for each app: profile, initial recommendation, current status (planned, in progress, delivered, under review), and any deviation explained.
This also helps with internal alignment: when someone wonders "why is this app a rehost and not a refactor?", the answer is documented and justified, not arbitrary.