Why technical dependencies block the choice of the 6R model Choosing between rehost, replatform, refactor, or rearchitect is never an isolated decision. Each application lives at the heart of an ecosystem of technical dependencies that weigh heavily on the feasibility and the final cost of the migration. An application that seems ideal for a simple rehost may prove impossible to move because it depends heavily on a critical on-premise database, a locked proprietary API, or a legacy integration that cannot be untangled quickly. These dependencies are not details to refine late in the project: they are major decision factors that must be identified from the initial assessment. Without this analysis, you risk choosing a 6R model that looks optimal on paper but that becomes a pit of costs and delays once operational reality hits. This is why any 6R model selection must rest on a prior audit of dependencies.
The four categories of dependencies that weigh on the migration Technical obstacles to migration do not arise at random: they group into four broad families, each posing different risks depending on the 6R model chosen. First, data dependencies: an application that depends on an on-premise database shared with other systems cannot migrate on its own with a simple rehost. You must either migrate the database too (increased complexity) or set up a remote access layer (latency, network costs). Next, integration dependencies: if your application exchanges flat files with a legacy system every day, or calls on-premise APIs, you must validate that this connection will work just as well from AWS. Compliance dependencies come next: some sectors (finance, healthcare, defense) require sensitive data to remain physically on-premise or within a specific AWS region. Migrating the application but not the data poses an insoluble problem. Finally, architectural dependencies: a 15-year-old monolithic application that has grown according to business needs, without an overhaul, sometimes accumulates internal couplings so tight that a simple rehost would be unstable. An overhaul (refactor or rearchitect) then becomes almost mandatory. Identifying which category each blocker falls into directly points toward the appropriate 6R model.
Auditing data dependencies before choosing rehost or replatform Data dependencies are often the most visible, but also the most underestimated in their impact on total cost. Start by mapping: who accesses which data, from where, and at what frequency? If your application writes to a database shared with three other on-premise systems, migrating with a simple rehost means leaving that database on-premise and routing the queries through a VPN or a Direct Connect. It is technically possible, but it adds latency (impacting user performance), increases network costs (AWS bills egress), and creates a persistent dependency on the on-premise infrastructure, contradicting the expected benefit of the migration. Replatform then becomes attractive: isolate a copy of the database in AWS (or integrate a managed RDS database), then synchronize the data between on-premise and cloud in near real time via an ETL or native replication. It is heavier than rehost, but it eliminates the long-term dependency. In other cases, the database itself must migrate as a priority: some on-premise relational databases can be converted directly to RDS (same engine), others require a refactor toward a cloud-native database (Aurora Serverless, DynamoDB). Before validating the 6R model, test the data synchronization between on-premise and cloud on a real subset: measure the added latency, the consistency delays, and the AWS costs. This audit takes a few days, but it avoids a bad decision that would cost months in corrections.
Assessing the integration and compliance dependencies that lock in the model An application may be technically autonomous in terms of data, but deeply attached to its operational context through integrations. Systematically audit: which external systems call this application, and which external systems does it call? If it consumes a legacy API, check whether that API can work from AWS (some require a fixed on-premise IP for obsolete security reasons). If it exposes an API that other systems consume, consider a light replatform at minimum to place a cloud API Gateway in front of it, otherwise the callers will all have to be rewired. File-based integration dependencies (regular uploads/downloads, EDI, batch transfers) are also sticking points: migrating without reworking these circuits means keeping on-premise/cloud bridges that slow things down and cost a lot. Compliance often frames what is feasible. In the financial sector, some client data cannot leave a data center in the region. In healthcare, health data must stay in the same geographic zone and respect specific certifications (HDS in France, HIPAA in the US). An innocent rehost becomes impossible if the data must stay on-premise: you then have to consider a hybrid (application in AWS, on-premise data synchronized), or accept staying entirely on-premise (retain). Compliance is assessed early in partnership with the compliance or legal lead of your organization, not at the end of the project when everything is already decided. Checklist: verify the data locality clauses, the required certifications, the expected annual audits, and the reaction times in case of an incident.
The architectural dependencies that make refactor or rearchitect mandatory Beyond data, integrations, and compliance, the internal structure of the application itself can be a blocker. A monolith of 500K lines of code where each layer depends heavily on the others, without a clean API between the modules, does not migrate well with a pure rehost. The behavior can change subtly on top of AWS (different network latency, thread timing, system file access), and without a modular structure, locating the bug becomes hellish. For these fragile architectures, replatform offers a light improvement (a cloud environment more stable than the aging on-premise), but refactor becomes almost mandatory if you really want to benefit from it. Refactor means keeping the business logic but reorganizing the application: isolating the modules into separate services (microservices), adding clean APIs between them, extracting the business logic into decoupled layers. It is heavier than a simple rehost, but it makes the application stable in the cloud and, above all, maintainable long term. Rearchitect (a total rewrite) is considered when the current architecture accumulates so much debt that refactoring would cost as much as rewriting. Assess these architectural dependencies by measuring: the coupling between modules (do they share global state, common data?), the test coverage (is there a suite sufficient to validate the overhaul?), and the age and knowledge of the code (does the current team understand the code well enough to refactor it without breaking it?). If the coupling is strong, the tests weak, and the code very old, refactor risks being more expensive than rearchitect.
Concrete checklist for auditing dependencies before the 6R decision Waiting for the detailed planning phase to audit dependencies is too late. The initial assessment (two to four weeks) must include this audit. Here is a concrete checklist, applied to each application that is a candidate for migration. First, data: list all the databases the application accesses (own databases, shared databases, data warehouses), note for each whether it is read-only or read-write, measure the frequency of the calls (daily batch, real-time queries), and identify the other consumers of these databases. For shared databases, estimate the cost and timeline of migrating the database too. Next, integrations: enumerate each external system your application communicates with, note the protocol (REST API, SOAP, batch files, message queues), verify whether the target (on-premise or another cloud) can communicate with AWS without a network blocker, and test a proof-of-concept connection. Then, compliance: consult the business and regulatory rules (GDPR, HIPAA, sector directives) and record the locality constraints, required certifications, audit trails, and compliance deadlines. Finally, architecture: note the programming language and the age of the code, measure the coupling index (how many modules share global state), verify the test coverage (ideally over 60%), and assess the current team's ability to refactor or whether external expertise is needed. Once this checklist is completed for each application, map the results onto a simple matrix (X axis: dependency complexity, Y axis: business stakes), then rank the applications to migrate by priority and by recommended 6R model. This audit takes one to two weeks per group of applications, but it solidifies your migration strategy by eliminating bad surprises.
How dependencies influence the 6R selection matrix Once the dependency audit is wrapped up, this information feeds directly into the 6R selection matrix. The classic matrix considers three axes: business impact, technical complexity, and urgency. The dependency audit adds a fourth decisive factor: the cost and timeline of mitigating the identified blockers. An application with high business impact, technically simple, but riddled with dependencies (shared database, legacy API, severe compliance) will never be a pure rehost, even if it would seem so without this audit. It becomes replatform at minimum, or even refactor if the architectural dependencies are heavy. Conversely, a less visible application with minimal dependencies (own data, simple integrations, modular architecture) can be rehosted in the first quarter, freeing up resources for the more complex cases. This prioritization based on the audit avoids the classic Tetris effect of migrations: choosing the easy cases first because you can, then hitting a big dependency mid-project and slowing down everything else. The matrix integrates the dependency audit as a weighted decision: each 6R model receives a feasibility score (rehost = 5 if no critical dependencies, 1 if multiple dependencies), and the chosen model is the one that maximizes business impact while minimizing residual dependencies. Those who take the time to audit dependencies well from the assessment onward genuinely accelerate the total migration, by moving the complex cases later when the team has the experience and the tooling.