Migrating Monolithic Apps to AWS: The 6Rs Framework in Practice

A month into my role and I am deep in migration assessments. We have hundreds of applications that need to move to AWS, and the single most important lesson I have learned so far is this: there is no one migration strategy. The right approach depends entirely on the application, its dependencies, its business criticality, and the appetite of its owning team for change.

AWS and Gartner popularized the "6Rs" framework for cloud migration, and I have found it to be genuinely useful as a thinking tool. Not as a rigid checklist, but as a vocabulary for discussing what we are actually going to do with each workload.

The 6Rs, From the Trenches

Rehost (lift and shift): Take the application as it is and move it to EC2. Same OS, same configuration, same architecture. This is the fastest path and the lowest risk, but it captures the least cloud value. You are essentially renting servers instead of owning them, which has cost and operational benefits but does not fundamentally change the application.

We use rehost for applications that are stable, not under active development, and scheduled for eventual retirement. Moving them to EC2 gets them out of the data center without investing engineering effort in something that has a finite lifespan.

Replatform (lift, tinker, and shift): Make a few targeted changes during migration to take advantage of cloud services. Swap the self-managed MySQL instance for RDS. Replace the NFS mount with EFS. Move the cron jobs to CloudWatch Events triggering Lambda functions. The application architecture stays largely the same, but you shed operational burden on specific components.

This is our most common approach. The ROI is excellent: small changes yield significant operational improvements. Moving a database to RDS alone eliminates patching, backups, failover configuration, and monitoring setup. That is weeks of operational work that simply disappears.

Repurchase (drop and shop): Replace the application with a SaaS equivalent. That custom-built CMDB? Maybe ServiceNow does the job. The homegrown monitoring system? CloudWatch or Datadog might be a better investment of engineering time.

This is harder than it sounds. Custom applications exist for a reason, usually because the requirements were specific enough that off-the-shelf solutions did not fit at the time. Whether those requirements still hold is a conversation worth having, but it is a business conversation, not a technical one.

Refactor (rearchitect): Fundamentally change the application architecture to be cloud-native. Decompose the monolith into microservices. Adopt event-driven patterns. Move to containers and serverless where appropriate.

This delivers the most cloud value but carries the most risk and cost. We reserve this for applications that are under active development, strategically important, and have teams willing to invest in the transformation. Refactoring a stable application that nobody touches is a waste of money.

Retire: Turn it off. In any large enterprise, a meaningful percentage of the application portfolio is no longer needed. Applications that serve a handful of users, tools that duplicate functionality available elsewhere, systems that were built for a one-time project and never decommissioned. Identifying these applications and retiring them is the easiest win in any migration program.

We have found that 10 to 15 percent of the portfolio falls into this category. That is significant, both in terms of infrastructure costs saved and operational complexity eliminated.

Retain: Leave it where it is, at least for now. Some applications have hard dependencies on on-premises hardware, regulatory constraints that prevent cloud hosting, or are so deeply integrated with other on-premises systems that migrating them would require migrating half the data center first.

Retain is not a failure; it is a pragmatic acknowledgment that not everything moves at the same pace. The important thing is to make it a conscious decision rather than a default.

The Assessment Framework

For each application, we gather a standard set of information:

Technical profile: Language, framework, dependencies, data stores, integration points, resource requirements.
Operational profile: Uptime requirements, deployment frequency, incident history, monitoring coverage.
Business profile: User base, revenue impact, strategic importance, active development status.
Migration complexity: Dependency depth, data volume, compliance requirements, team readiness.

We score each dimension and use the scores to recommend a migration strategy. The scoring is not algorithmic; it is a structured way to ensure we consider all the relevant factors before making a recommendation.

Dependency Mapping Is Everything

The hardest part of enterprise migration is not moving individual applications. It is understanding the dependency graph between them. Application A talks to Application B over a private network connection. Application B reads from a database that is also used by Applications C and D. Application D has a batch job that feeds data to a mainframe.

You cannot migrate A without understanding its relationship to B, and you cannot migrate B without understanding C, D, and the mainframe. Migration planning at enterprise scale is fundamentally a graph problem.

We have invested heavily in dependency discovery tools. AWS Application Discovery Service helps, but it only captures network-level dependencies. Understanding application-level dependencies, which service calls which API, which process reads from which database table, requires a combination of automated discovery, architecture documentation (when it exists), and conversations with the teams that own the applications.

The Migration Factory Model

At the scale we operate, treating each migration as a unique project does not work. We need repeatable processes. The migration factory model breaks the work into standardized phases:

Discover: Inventory the application and its dependencies.
Assess: Determine the migration strategy and estimate effort.
Mobilize: Set up the target environment, networking, security, and access.
Migrate: Execute the migration according to the chosen strategy.
Validate: Confirm functionality, performance, and security in the new environment.
Optimize: Right-size resources, implement cloud-native monitoring, refine configurations.

Each phase has standard deliverables, checklists, and gates. This does not eliminate the need for engineering judgment, but it does ensure that we do not skip critical steps and that we learn from each migration and feed those learnings back into the process.

What I Have Learned So Far

Start with the easy wins. Migrating a complex, business-critical application first is tempting because it demonstrates value, but it also carries the highest risk. Start with simpler applications to build the team's confidence and refine the process. The hard ones will still be there.

Migration is a team sport. The cloud team cannot migrate applications in isolation. We need the application teams, the security team, the networking team, and the database team involved at every stage. The technical work is often the easiest part; the coordination is what takes time.

Data gravity is real. Applications follow their data. If the database stays on-premises, the application will too, or at least it will perform poorly if you try to separate them by a network hop. Data migration strategy needs to lead application migration strategy, not follow it.

Cost modeling is harder than expected. Comparing on-premises costs to AWS costs is not apples to apples. On-premises costs are buried in data center leases, power bills, hardware refresh cycles, and staff time that is allocated across multiple systems. Building an honest cost comparison requires forensic accounting, not just plugging numbers into the AWS pricing calculator.

We are six weeks in and we have migrated our first batch of applications: a handful of rehost candidates and two replatform projects. The process is working. The scale is daunting. But we have a framework, a team, and a growing body of experience to draw on.

One application at a time. Hundreds to go.