Migration & Modernization
Speed to Value: Why Migrate-First Still Wins at Scale
Introduction
Lift-and-shift has a reputation problem. Ask any enterprise architect and you’ll get a wince. “We just moved our problems to the cloud.” That criticism has a grain of truth – but only when migration is treated as the end goal. The real question is whether it’s the right first step. Often, it is.
Here’s what four years of enterprise migrations have taught me: the problem isn’t migrating first. It’s what customers do – or don’t do – next.
An internal AWS study shows rehosting accounts for 35–50% of workloads. Another 20% follow a replatform path. Only around 10% involve full refactoring. That’s how enterprise migrations actually unfold – and it points to a three-stage motion that works: Migrate, Optimize, Modernize.
Each stage builds on the last. Migration gets you to the cloud. Optimization unlocks the immediate economics. Modernization compounds the value over time. Done in sequence, at a pace the organization can sustain, this is how large enterprises get the most from AWS.
Why ‘Modernize Everything at Once’ Can Stall at Scale
The appeal of going straight to cloud-native is real. Skip the interim steps. Get to microservices, serverless, and containers in one move. Clean slate.
It’s an ambition I’ve seen often. And when scope isn’t managed carefully, it’s where programs can run into trouble.
The core issue is complexity at scale. Modernizing one application is straightforward. Modernizing 300 simultaneously – while managing data center exit deadlines, hardware end-of-life, license renewals, and BAU – is a different problem entirely.
Risk compounds quickly – when application #47 runs three months late, it can threaten the entire data center exit, and scope creep becomes structural.
AWS Prescriptive Guidance is clear:
“Refactor is not recommended for large migrations because it involves modernizing the application during the migration. Instead, we recommend rehosting, relocating, or replatforming the application and then modernizing after migration is complete.”
The AWS guidance explicitly endorses migration-first as a valid strategy at scale – get workloads to the cloud, then modernize from a stable foundation.
The Economics of Migrate, Optimize, Modernize
Migration changes your cost structure from day one. Fixed infrastructure spend becomes consumption-based. Hardware refresh cycles disappear. You pay for what you use, not what you provisioned three years ago.
3M is a good example. The company migrated thousands of applications to AWS using AWS Application Migration Service – a migration-first approach designed to exit aging data centers with minimal downtime. Following the migration, 3M moved selected workloads to Amazon Relational Database Service (Amazon RDS) and introduced AWS Lambda capabilities. Migrate first, modernize after. The cloud became the platform for innovation, not merely a new location for old infrastructure. The move to Amazon RDS is a classic replatform – a managed service swap that cuts operational overhead without re-architecting.
Figure 1 shows how the economics build at each stage – from the initial migration through to a fully optimized AWS environment.
Figure 1: Financial Walk to Target State
Economics build in layers. At migration and immediately after:
- Rightsizing – on-premises servers average only 12–18% utilization (IBM); rightsizing closes that gap from day one.
- Commitment pricing – Reserved Instances and Savings Plans reduce costs by up to 72% vs on-demand.
- Storage optimization – Amazon Simple Storage Service (Amazon S3) tiers, Amazon Elastic Block Store (Amazon EBS) rightsizing, and lifecycle policies reduce storage spend.
- Elasticity – dev/test environments scale down or off outside business hours.
As you modernize, the economics improve further:
- Managed services – managed databases, containers, and analytics services reduce operational overhead.
- License optimization – moving from commercial databases to open-source or AWS-native equivalents reduces licensing costs.
- Cloud-native patterns – serverless and event-driven architectures eliminate idle capacity entirely.
None of the migration-stage optimizations require re-architecting your applications. But they do require intentional work. The migration is the enabler; the savings come from what you do with it.
When Migration First Is the Right Call
The answer depends on why you’re migrating. Migration first makes sense when you have a forcing function:
- Data center exit or lease expiry – you have a hard date, no flexibility.
- Hardware end-of-support – vendor support ending on physical servers or storage.
- License cliff – a renewal approaching at a cost that makes migration compelling.
- M&A activity – consolidating infrastructure under a tight timeline.
- Security or compliance deadline – an environment you can no longer adequately harden.
In these scenarios, the question isn’t “should we modernize?” It’s “how do we exit before the deadline?” Migration gets you out. Once in the cloud, you can optimize and modernize at a pace that fits your team.
Migration first is the right default for most large portfolios – but not every workload. There are clear scenarios where going straight to cloud-native delivers better outcomes.
When to Modernize Directly
There are scenarios where going straight to cloud-native is the right call:
- The portfolio is small (<20-30 applications) and scope is manageable.
- The application is planned for a significant rewrite.
- The team has strong cloud-native skills.
- Technical debt makes migration a short-term fix – a rewrite is already planned or inevitable.
- A SaaS replacement exists and makes migration moot.
- Compliance requirements demand architectural change regardless.
For most large enterprise portfolios, the answer isn’t all migrate or all modernize. It’s a portfolio split – one that real-world AWS migrations consistently reflect:
| Strategy | Typical % | When It Applies |
|---|---|---|
| Retire | 10-20% | No longer actively used – switch it off |
| Retain | 5-10% | Not ready; revisit later |
| Rehost | 35-50% | Commodity workloads, forcing function, speed priority |
| Replatform | ~20% | Managed DB, containers, license swap – no architectural redesign |
| Refactor | ~10% | High-value, business-critical systems requiring architectural change |
| Repurchase | 5-10% | Replace with SaaS |
Source: Internal AWS study, cited in AWS Partner Training Series on Modernization Pathways (2023)
The key insight: you don’t modernize everything. The ROI of refactoring a commodity internal tool rarely justifies the effort. Migrate that application. Invest your modernization budget in systems that actually drive competitive advantage.
Migration as Launchpad
Stephen Orban, former VP of Enterprise Strategy at AWS, put it well:
“We’ve also found that applications are easier to optimize/re-architect once they’re already running in the cloud. Partly because your organization will have developed better skills to do so, and partly because the hard part – migrating the application, data, and traffic – has already been done.”
– Stephen Orban, “6 Strategies for Migrating Applications to the Cloud“, AWS Enterprise Strategy Blog
This is what migration critics miss. Once an application is in the cloud, your team has:
- Learned how it actually behaves under real conditions.
- Instrumented it with Amazon CloudWatch and found what they didn’t know.
- Established a cost baseline to optimize against.
- Built skills and confidence with AWS tooling.
Optimizing and modernizing from that position is fundamentally easier. The blast radius is smaller, the team is more capable, and the unknowns are known.
A Practical Decision Framework
For any given application, ask four questions:
1. What’s the driver?
- Forcing function → migrate to meet the deadline, optimize and modernize to a roadmap.
- Strategic value creation → evaluate modernization ROI before committing.
2. What’s the strategic value?
- Customer-facing, competitive differentiator → invest in modernization.
- Commodity, maintenance mode → migrate, optimize, or retire.
3. How ready is the team?
- Strong cloud-native skills → modernize directly if other factors support it.
- Still building skills → migrate first; let real cloud experience accumulate.
4. What’s the risk tolerance?
- Low (regulated, complex interdependencies) → migrate first to minimize blast radius.
- Higher (strong engineering culture) → direct modernization may be viable.
Value Across the Journey: The AWS Cloud Value Framework
Infrastructure cost is only part of the story. The AWS Cloud Value Framework measures value across five pillars. Each stage of the journey – Migrate, Optimize, Modernize – unlocks more value across every dimension.
| Value Pillar | Migrate | Optimize | Modernize |
|---|---|---|---|
| Cost | Consumption-based pricing, no hardware refresh, pay for what you use | Rightsizing, commitment pricing, storage optimization, elasticity | License savings, managed service efficiency, serverless eliminates idle compute |
| Staff Productivity | Less data center management, no hardware procurement cycles | Automation, tagging, self-service provisioning reduces manual effort | Less patching, faster deployments, focus shifts to higher-value work |
| Operational Resilience | Multi-AZ redundancy, automated backups, no single points of failure from aging hardware | Monitoring and observability with CloudWatch, faster incident response | Managed services add built-in HA; cloud-native patterns enable auto-scaling |
| Business Agility | Provision new environments in minutes, not weeks | Faster release cycles as infrastructure overhead reduces | Microservices and CI/CD enable deployment in hours, not months |
| Sustainability | Shared infrastructure improves utilization vs dedicated on-premises | Right-sized workloads use less energy than over-provisioned on-premises | Serverless and event-driven architectures eliminate idle compute entirely |
The table shows why migration is a strong first step – not a compromise. Every pillar improves from day one. Optimization and modernization compound that value further.
The journey isn’t about paying twice. It’s about unlocking each layer of value in sequence, at a pace the organization can sustain.
The Bottom Line
In this post, I showed how a three-stage approach – Migrate, Optimize, Modernize – delivers faster time to value for large enterprise portfolios than attempting full modernization in a single pass.
Getting out of the data center is a genuine milestone – no more hardware refresh cycles, no more capacity guessing, infrastructure that scales with the business. What comes next is where the economics really open up: the managed database migration that halves licensing costs, the serverless function that retires three servers, the ML model deployed in an afternoon.
But you don’t get there if you’re locked in a three-year modernization program that never finishes – while the data center contract counts down and the team burns out.
Migrate deliberately. Optimize immediately. Modernize strategically. For most large portfolios, the right answer is all three – in that order.
Ready to plan your migration and modernization journey?
Talk to your AWS account team about an AWS Transform assessment, or explore the AWS Migration Acceleration Program to get started with funded support for your first wave of workloads.