Key Takeaway
Most AWS migration failures start before any code moves. Pick incremental, big bang or hybrid based on how critical and how entangled each application is, and treat security as part of the design rather than a step after cutover.
Legacy systems are usually stable. That’s the problem. They work well enough that nobody wants to touch them, right up until the hardware ages out or a vendor drops support.
Moving them to AWS is mostly a planning exercise, not a technical one. This article covers how to choose a migration approach, which services do the actual work, and the four mistakes that cost the most.
Why move to AWS at all?
Five reasons, and only some of them will apply to you.
Scaling that matches demand. You stop provisioning for peak and paying for it year-round.
Cost that follows usage. This is true if you manage it and false if you don’t. Lift-and-shift with no resizing usually costs more than the data centre it replaced.
Access to managed services. The real win for most teams. Not running your own database failover is worth more than the compute savings.
Redundancy you’d otherwise build. Multi-AZ deployment is a configuration setting instead of a project.
Security infrastructure. You inherit a lot, and you still have to configure your half correctly.
If your only reason is cost, check the math carefully before committing. If your reason is that your team spends a third of its time on infrastructure maintenance, the case is much stronger.
Which AWS services do the work?
Database Migration Service (DMS) moves databases while the source stays live. That’s the feature that matters: you replicate continuously, verify the target, and cut over during a short window instead of a weekend outage.
EC2 gives you resizable compute. It’s where lift-and-shift workloads land, and it’s the least interesting destination. Treat it as a stepping stone rather than an end state.
RDS runs your relational database and handles backups, patching and failover. Moving from self-managed Postgres on EC2 to RDS is often the single biggest operational win in a migration.
S3 takes your large data sets and archives. Storage classes matter here: data you touch once a year shouldn’t sit in Standard.
IAM controls who can do what. Get this wrong early and you’ll spend months unwinding it, so design roles before you create them.
Which migration approach should you choose?
Incremental
Move components a piece at a time. Lower risk, because you test at each stage and disruption stays contained. Your team builds AWS experience on small pieces before touching anything critical, and you can optimize as you learn.
Think of it as renovating room by room. You keep living in the house.
The cost is duration and complexity. You run two environments at once, sometimes for a year, and the integration between them is real work.
Big bang
Move everything in one planned cutover. Clean break, no parallel environments, and for a small application it’s genuinely faster.
It also concentrates all your risk into one window. This works when the application is simple, dependencies are few, and you can roll back fast. It fails badly when any of those aren’t true.
Hybrid
Most organizations end up here, and it’s usually the right answer. Move critical, entangled systems incrementally. Move simple standalone applications in one shot.
Pick per application based on four things: how critical it is, how entangled it is with other systems, how much downtime the business tolerates, and how much AWS experience your team has today.
What actually goes wrong?
1. Planning that skips the assessment
Most failures are visible before anything moves. Teams jump to execution because planning doesn’t feel like progress.
Before you touch anything: document every application dependency, including the ones nobody remembers. Measure current performance so you can tell whether the migration made things worse. Identify compliance requirements. Write migration runbooks. And write the rollback plan, because you will need it at least once.
The assessment phase should take weeks. If it took days, you missed something.
2. Data transfer costs nobody modelled
Transfer charges add up fast, and they surprise people because the compute estimate was the one everyone reviewed.
Model the volume you’re moving, the bandwidth you have, and AWS transfer pricing for your path. For large data sets, physical transfer with Snowball often beats the network. Then account for ongoing synchronization during the parallel-run period, which is the line item teams forget entirely.
3. Security bolted on afterward
Security is a design input, not a migration phase.
Encrypt data at rest and in transit from the first workload. Define IAM policies and roles before you start creating them ad hoc. Segment the network with VPCs. Confirm your compliance obligations hold in the new environment. Turn on monitoring and logging on day one, not after the first incident.
Retrofitting any of these across a migrated estate costs several times what doing it upfront would have.
4. Treating cutover as the finish line
The migration ends when operations are stable, not when traffic switches.
Plan monitoring and alerting, backup and recovery procedures, patch management, cost optimization and ongoing security management before cutover. Teams that skip this discover in month two that nobody owns the new environment.
What does good practice look like?
Define success in numbers. Performance benchmarks, cost targets, timeline milestones, compliance requirements. “Migrate to AWS” isn’t an objective. “Serve p95 under 200ms at 40% lower infrastructure cost by Q3” is.
Choose services deliberately. Managed or self-managed, serverless or traditional compute, which database service, which storage tier. Defaulting everything to EC2 is how you end up with a data centre that happens to be in Virginia.
Test more than functionality. Functional testing, performance testing under real load, security and penetration testing, disaster recovery testing, and user acceptance. The DR test is the one teams skip and the one that matters most.
What this actually buys you
Less time spent on infrastructure and more on the product. That’s the honest version.
The teams that get the most out of a migration are the ones that treat it as an opportunity to fix operational debt, not just to change where the servers live. Moving a badly monitored, manually deployed application to AWS gives you a badly monitored, manually deployed application with a bigger bill.
Frequently Asked Questions
What’s the best migration strategy for legacy applications?
A hybrid one, for most organizations. Move critical interconnected systems incrementally so you can test at each stage, and move simple standalone applications in a single cutover. The mix depends on dependencies, uptime tolerance and how much AWS experience your team already has.
How long does an AWS migration take?
A single application with few dependencies takes weeks. An enterprise portfolio of interconnected legacy systems takes 12 to 24 months. Budget several weeks for assessment alone, before anything moves, to document dependencies and set performance baselines.
What are the most common hidden costs?
Data transfer during migration, running parallel environments through the transition, retraining the team, and post-migration cost optimization. Security configuration, compliance testing and performance tuning in the new environment are also routinely underestimated.
Planning a migration? Talk to our cloud team about your dependencies and constraints, or read how we handle managed DevOps after cutover.