The Six Pillars, Translated for Migration Teams
The six pillars are six inspectors, each examining a different system. They occasionally disagree about priorities, and resolving those tensions is where architectural judgment lives.
Operational Excellence
Can your team operate the migrated workload? Do you have runbooks for your new cloud environment? Have you defined what "healthy" looks like for each workload so you can distinguish a genuine outage from a Tuesday spike? Are deployments automated, or is someone still SSHing into a box and running scripts?
The migration-specific trap: assuming operational processes transfer from on-premises to cloud. They rarely do. Your monitoring tool may not understand auto-scaling groups. Your incident playbook may assume a single data center, not three availability zones. We made this exact mistake on a migration for a logistics company. Their on-prem runbooks referenced specific server hostnames and rack locations. In AWS, none of that existed. The first production incident after migration took 40 minutes longer to resolve than it should have because the on-call engineer kept trying to SSH into servers by hostname instead of using the new instance discovery workflow. Operational excellence during migration means rebuilding these processes, not porting them.
Security
Security during migration is not about whether you have a firewall. It is about whether you understand how the perimeter has changed. On-premises, your network boundary was physical: a building, a rack, a cable. In the cloud, the boundary is logical: IAM policies (identity and access management rules controlling who can do what), security groups (virtual firewalls around instances), and encryption configurations that are one misconfigured JSON document away from "public."
Who has root account access? Is MFA enforced for every human user? Are your secrets stored in a secrets manager or hard-coded in environment variables someone committed to Git in 2019? During migration, the security pillar verifies that the new front door has a lock, not just a decorative handle. These questions feel obvious until you try to answer them honestly.
Reliability
Reliability asks what happens when things break, because they will. RTO (Recovery Time Objective, maximum acceptable downtime) and RPO (Recovery Point Objective, maximum acceptable data loss) are not theoretical numbers for a document. They drive real architectural decisions: whether you deploy across multiple availability zones, whether your database has automated failover, whether your backups are tested or merely configured. "Configured" backups that have never been restored are not backups. They are assumptions.
For migration projects, reliability means understanding your recovery objectives and engineering to them. Does a burst pipe in the guest bathroom flood only the guest bathroom, or does it take out the entire electrical system? The review surfaces which workloads lack redundancy, which backups are untested, and which failure modes nobody has considered.
Performance Efficiency
Performance efficiency prevents you from installing commercial-grade infrastructure in a workload that doesn't need it, or trying to serve a high-traffic application with resources sized for a dev environment. In AWS terms, it means selecting the right instance types, storage tiers, and service configurations for your actual workload patterns, not the patterns you imagined during planning.
Migration teams lift and shift on-premises hardware specs into the cloud without questioning whether those specs were correct in the first place. The cloud's advantage is elasticity (scaling up and down with demand), but you only capture it if you design for it instead of treating VMs as more expensive versions of your old servers.
Cost Optimization
Cost optimization is the pillar that separates a successful migration from one that makes the CFO regret approving the project. It points out that you're heating rooms nobody uses, running sprinklers in January, and paying for security on a shed that was demolished last year.
Organizations without a formal cost management strategy routinely overspend by 20-50%. The offenders are familiar: oversized instances running at 10% utilization, development environments left running over weekends and holidays, storage volumes attached to instances that no longer exist, and data transfer costs nobody modeled during planning. The review forces you to confront these line items before they accumulate into an invoice that triggers an executive review meeting.
Cost optimization doesn't mean spending less. Sometimes the review reveals under-spending: a production database on an instance that can't handle peak load, or skipping multi-AZ for a critical workload to save a few hundred dollars a month. The goal is maximum value per dollar, not minimum cost.
Sustainability
The newest pillar asks about environmental impact. In practice it overlaps with cost optimization: wasted compute is wasted electricity. It also asks whether managed services would be more efficient, whether data retention policies keep data past its usefulness, and whether your architecture scales down as gracefully as it scales up. Many teams still treat this pillar as secondary, but teams that take it seriously often find cost savings they missed in the cost review.
Operational and security reality
Migration changes how systems are operated and defended. Porting old assumptions into cloud usually fails.
Reliability and performance judgment
RTO, RPO, redundancy, and sizing need to be engineered for the new environment, not inherited.
Cost and sustainability discipline
The framework surfaces wasted spend, hidden under-investment, and architectures that never learned how to scale correctly.
The Migration Lens: Three Phases
The Migration Lens overlays migration-specific guidance onto the six pillars. It maps across the three phases every migration traverses.
Assess
Catalog what exists, its condition, and its dependencies. Collect configurations, usage patterns, and behavioral data from existing servers. Build the business case. Decide what migrates, what gets retired, and what stays.
The questions here are diagnostic: Do you understand your current architecture well enough to migrate safely? Have you identified the dependencies that break if you move Application A before Application B? Do you know your actual resource utilization, or are you relying on specs from a procurement document five years ago?
Mobilize
Build foundational capabilities, both organizational and technical. Establish the landing zone (baseline AWS environment with networking, identity, and security configurations). Run pilot migrations: take the least-critical room and do a trial renovation to test your processes before you touch the kitchen.
During Mobilize, teams build hands-on experience. They define migration patterns and train people. The questions shift from "do you understand what you have?" to "are you ready to operate what you're about to build?" This is where security baselines get defined, monitoring gets configured, and runbooks meet reality. It's also where the gap between what people think they know and what they know about their systems surfaces.
Migrate and Modernize
Using patterns validated during Mobilize, migrate at scale. The framework acts as a quality gate, checking each workload against standards from earlier phases.
Migration isn't a project with a finish line. Workloads you migrate today need re-evaluation as usage patterns and AWS services change.
Assess
Inventory workloads, dependencies, and real utilization so the migration starts from evidence instead of assumptions.
Mobilize
Build the landing zone, test patterns, and train the organization before broad production movement.
Migrate and modernize
Use the framework as a quality gate while workloads move and continue re-evaluating them afterward.
Where Real Projects Go Wrong
The "Lift and Shift and Forget" Trap
Rehosting is a valid starting strategy. The problem is treating it as the final state. Two years later: same-sized instances, no auto-scaling, no reserved instances. Cloud prices for on-premises architecture.
We had a client running 47 EC2 instances, all m5.2xlarge, because that was roughly equivalent to their on-prem server spec. When we finally ran utilization analysis nine months post-migration, average CPU across the fleet was 11%. Thirty-one of those instances could have been m5.large or smaller. The monthly savings from right-sizing was around $14K. That's money they'd been burning since day one of the migration because nobody went back to question the initial sizing.
The Missing FinOps Discipline
FinOps (Financial Operations, bringing financial accountability to cloud spending) is not optional. It's the difference between a migration that stays on budget and one that balloons.
Real migration projects show a pattern: the first 3-4 months see 20-30% budget overruns. Organizations that establish a FinOps function (weekly spend monitoring, unused resource identification, auto-scaling policies, pricing negotiations) recover quickly. One case: 20% reduction in the following quarter, nearly 50% within a year. Organizations that treat cost as someone else's problem don't recover.
Stakeholder Misalignment
When application owners, data owners, security teams, compliance officers, and finance leaders aren't engaged during Assess and Mobilize, misalignment surfaces mid-migration: confusion about scope, disagreements about which applications migrate first, misunderstanding about testing expectations. The framework functions as an early-warning system because it asks questions that cross organizational boundaries. If the security team and the application team give different answers to the same Well-Architected question, you've found the misalignment before it becomes a production incident.
Rehost drift
Lift-and-shift is a starting move. Treating it as the final architecture is how cloud bills inherit on-prem inefficiencies.
No FinOps, no control
Without explicit financial accountability, early migration overruns compound instead of getting corrected.
Misalignment is architectural
When security, application, and finance teams disagree on reality, the migration risk already exists.
The Well-Architected Review as a Living Practice
AWS recommends reviews at least annually, plus before major changes. The teams that extract the most value treat it as continuous.
This means running relevant questions before building something new. Integrating the review into sprint planning, where cost and security implications are discussed while decisions can still be changed cheaply. Maintaining an improvement plan: a prioritized backlog of identified risks tracked with the same discipline as feature work.
The AWS Well-Architected Tool in the console is underrated. It walks you through pillar questions, records answers, generates risk reports (classified as high or medium), and tracks improvement plans over time. It's not magic, but it imposes structure on conversations that otherwise devolve into vague reassurances.
Teams struggle when they treat the review as a compliance exercise. The useful version is honest self-assessment, including marking a risk "high" when that is politically uncomfortable. A review full of "we're doing great" answers creates false security and blocks improvement.
The 7 Rs
Not every application needs the same migration treatment. Understanding which strategy fits each workload is one of the most consequential decisions in a migration project.
Retire means identifying applications that no longer serve a business purpose. They consume resources, generate alerts, and provide no value. Finding them during Assess saves real money. In the freight company case above, 5 of 47 applications were retired outright, which freed budget for the rest.
Retain means deciding a workload has legitimate reasons to stay on-premises: compliance restrictions, latency requirements, or a planned decommission that makes migration a poor investment.
Rehost is moving with minimal changes. Fastest strategy and the right starting point for many workloads. But it should not be the ending point. Workloads that are never optimized after rehosting produce cloud bills with data center economics: high fixed costs, low elasticity, no benefit from the managed services that justify cloud adoption.
Relocate moves VMware-based workloads to VMware Cloud on AWS. Same virtualization layer, different physical location.
Replatform makes targeted optimizations during migration. Self-managed database to Amazon RDS, for example. Self-managed Elasticsearch to Amazon OpenSearch. You upgrade the fixtures without renovating the whole room. This is often the sweet spot: meaningful improvement with modest effort.
Repurchase replaces a custom or legacy application with SaaS. The application stops being your problem to maintain. This is worth considering more often than most teams do. Custom software that was built a decade ago and maintained grudgingly is often better served by a modern SaaS product.
Refactor re-architects for cloud-native capabilities: containers, serverless, managed services, event-driven patterns. Most expensive and time-consuming. Greatest long-term benefits for applications that are strategic to the business and will need to scale significantly.
The review helps match strategy to application by surfacing criticality, dependency complexity, and operational burden. Applying the same strategy uniformly across a portfolio guarantees over-investment in some applications and under-investment in others. The guest bedroom needs paint, not a gut renovation. The kitchen needs the full treatment. The storage room nobody enters might just need boarding up.
Retire, retain, rehost, relocate
Some workloads should be removed, some kept, and some moved quickly with minimal architectural change.
Replatform and repurchase
Targeted modernization and SaaS replacement often create better economics than carrying every custom layer forward.
Refactor selectively
Deep cloud-native redesign belongs to strategically important systems that justify the cost and complexity.
What a Migration Actually Looks Like
A mid-market freight coordination company (roughly 400 employees, $180M revenue, 47 applications across two data centers) got approval for a migration to AWS with a 14-month timeline and $2.4M budget.
They started with enthusiasm and a rehost-everything strategy. By month four they had migrated 18 applications and burned through 45% of the budget. Instances sized to match on-prem counterparts. Dev and staging environments running 24/7 because nobody configured scheduling. Three DMS instances still running from early waves, accumulating charges for work that finished months earlier.
The CTO engaged an AWS partner for a Well-Architected review. Findings across every pillar. Security: default EBS encryption not enabled, four IAM users with static access keys older than 18 months never rotated. Reliability: only 6 of 18 migrated applications deployed across multiple availability zones, none with tested backup restoration. Cost: 31% of instances oversized by at least one family step, 14 EBS volumes attached to instances stopped for months. Operational excellence: monitoring configured only for applications the team considered "critical," meaning non-critical applications could fail silently for days.
They built an improvement plan prioritized by risk. Right-sized instances, saving 22% on compute in the first quarter. Terminated zombie resources. Implemented tagging so every resource had an owner and cost center. Established a FinOps cadence: weekly cost reports to engineering leads, monthly deep dives with finance.
The remaining 29 applications migrated over eight months. For each wave, a lightweight Well-Architected checklist before cutover, focused on the questions that had surfaced the most significant risks. Total migration completed in 16 months (two past timeline, within adjusted budget) with annual infrastructure costs 28% below the on-premises baseline.
Initial enthusiasm
The migration started with a rehost-everything mindset and moved quickly into overspend and drift.
Structured review
A Well-Architected assessment surfaced concrete security, reliability, cost, and operational gaps.
Improvement plan
Right-sizing, tagging, cleanup, and FinOps cadence turned findings into tracked engineering work.
Controlled completion
Later migration waves used lighter repeated checks and finished with lower annual infrastructure cost than the original baseline.
Common Misconceptions
"The framework is a compliance checkbox." The value is in the conversation, not the report. A review full of green checkmarks that don't reflect reality creates false security.
"You do the review once and you're done." Migrations evolve. New workloads arrive, usage patterns shift, AWS releases services that invalidate previous decisions. The framework is designed for repeated application.
"Lift and shift means the framework doesn't apply." Backwards. Rehosted workloads are most likely to have unaddressed risks because the strategy explicitly avoids changing the architecture. If you rehost an application with poor security practices, you now have poor security practices in the cloud, except the blast radius is larger because cloud resources are internet-accessible by default unless configured otherwise.
"Cost optimization means spending less." Sometimes the review reveals under-spending: a production database on an instance that can't handle peak load, or skipping multi-AZ for a critical workload to save a few hundred dollars a month.
"The framework is only useful for large enterprises." A startup with three services benefits from asking "what happens when this fails?" and "who is paying for this resource?" just as much as a Fortune 500.
The report is not the value
A green review without honest answers is worse than useless because it creates false confidence.
Rehosted workloads still need scrutiny
Avoiding architectural change does not avoid architectural risk. It often preserves it.
Cost optimization is about value
The right answer is not always lower spend. Sometimes the framework surfaces under-investment in critical reliability.
Takeaways
- The Well-Architected Framework is a diagnostic conversation whose value comes from honest answers, not favorable reports.
- Lift and shift is a starting strategy, not a destination. Workloads never optimized after migration produce cloud bills with data center economics.
- FinOps is not optional: migration projects without financial accountability routinely overspend by 20-50%.
- Zombie resources (orphaned volumes, stopped instances, forgotten DMS nodes) are the silent budget killer.
- Match the migration strategy to the application using the 7 Rs. Uniform strategy across a portfolio guarantees misallocation. A workload approaching end-of-life deserves Retire. A strategic, high-growth application deserves Refactor. Everything in between deserves deliberate assessment.
- Stakeholder alignment is an architectural concern. When security, application, and finance teams give different answers to the same Well-Architected question, you've found a misalignment that will become a migration risk. Surface these during Assess and Mobilize, when correcting course is cheap.
- The review is a repeating practice: before migration, during migration, and at least annually afterward. Workloads change. AWS services change. The review catches the drift.
