Migrating to AWS Without Downtime: Planning a Move the Business Won't Feel

The migration playbook for systems that can't stop: dependency mapping, rehost vs. re-architect per component, parallel running, rollback plans, and what the first 30 days on AWS should look like.

The riskiest migrations aren't the technically hard ones. They're the ones running a live business. Every order, login, and payment keeps flowing while you move the ground underneath it. The goal isn't a clever architecture. It's that on Monday morning nobody notices anything changed except the bill and the dashboards.

Zero downtime is mostly a planning problem, not a tooling one. AWS gives you the primitives. Whether the business feels the move comes down to decisions you make weeks before cutover: what depends on what, what moves untouched, what runs in parallel, and how fast you can undo it. Here's how we sequence it.

Map every dependency before you touch a server

You can't move what you can't see. Start with discovery, not architecture. Almost every legacy system has connections nobody remembers: a reporting job that hits the production database directly, a partner pulling files over SFTP, a hardcoded IP in a firewall rule.

Capture network traffic —netflow, tcpdump, connection tracking— for two to four weeks to catch the monthly and quarter-end jobs. AWS Application Discovery Service helps, but the network capture is the ground truth: it shows what the system actually does, not what the documentation claims it does.

• Every inbound and outbound connection, with port, protocol, and frequency
• Scheduled jobs: cron, ETL windows, month-end batches, backups
• Shared state: databases, file shares, message queues, caches
• External integrations: payment gateways, partner APIs, DNS, email/SMS providers
• Licensing and anything tied to a MAC address or a fixed IP

Decide per component: rehost, replatform, or re-architect

Not everything deserves the same treatment. The "6 R's" framework is useful, but in practice most components fall into three buckets. Deciding one component at a time is what keeps the timeline honest.

• Rehost (lift and shift): move the VM as-is. Fastest, lowest risk. Right for stable apps you'll retire later or that aren't worth re-engineering.
• Replatform: keep the app, swap the substrate —self-managed PostgreSQL to RDS, a VM to a container on ECS/EKS. Managed backups, patching, and failover with modest code change.
• Re-architect: rewrite for the cloud —break up a monolith, go serverless. Highest value, highest risk, longest timeline.

The trap is re-architecting during the migration. Moving and redesigning at once multiplies risk and makes rollback nearly impossible. Rehost first, get stable on AWS, then modernize from a place of safety. A migration is a bad time to also be shipping new architecture.

Run old and new in parallel, and get data sync right

Zero downtime means the old system stays authoritative until the new one has proved it can take real traffic. The hard part is keeping data consistent across both while they run together.

For databases, continuous replication is the workhorse. AWS DMS handles homogeneous and heterogeneous replication with change data capture, so the target stays current with the source in near real time. For PostgreSQL to PostgreSQL, native logical replication is often cleaner. Let it run for days, validate row counts and checksums, and watch replication lag before you even think about cutover.

• Replicate continuously, not with a one-time dump: the gap between dump and cutover is where data goes missing
• Validate with row counts, checksums, and business-level reconciliation, not just "it connected"
• Decide direction: one-way to the new system, or bidirectional if you need a safe path back
• Test the new stack with mirrored production traffic (shadow traffic) before real users hit it

Cut over in a way you can reverse in minutes

The cutover is the only moment users can feel. Keep it short, reversible, and boring. Blue-green is the default: the new environment fully live in parallel, then you shift traffic, with nothing flipped all at once.

Control the shift with DNS or a load balancer. Lower the DNS TTL to 60 seconds days ahead so clients pick up the change fast. Better, put a Route 53 weighted or failover record —or an ALB— in front and move traffic in percentages: 5%, 25%, 50%, 100%, watching error rates and latency at each step. Never flip 100% at once on a system that matters.

• Drop the DNS TTL to 60s at least 48h before, so rollback propagates fast too
• Shift traffic gradually and watch p95 latency, 5xx rate, and business metrics (orders, logins)
• Pick a low-traffic window, but don't lean on the window: lean on reversibility
• Freeze deploys and schema changes during the cutover window

Write the rollback plan before you need it

Every migration needs a defined answer to "it's going wrong, now what?" —decided in advance, with a named owner and a threshold that triggers it. If error rate crosses X or reconciliation fails, you roll back without calling a meeting.

• A concrete trigger: a specific error rate, latency, or data-integrity threshold, not a gut feeling
• The old environment kept warm and authoritative until the new one is proven: don't decommission on day one
• A tested path back: if data was written to the new system, how does it get back to the old one? Bidirectional replication or a reconciliation job
• One person with authority to call it and a rehearsed runbook: rollback fails when it's improvised

The first 30 days decide whether it stuck

Cutover isn't the finish line. The first month on AWS is where hidden costs, misconfigurations, and scaling surprises surface. Plan for it as a phase, not an afterthought.

Two things bite most teams early: cost and security. A lift-and-shift that ran fine on fixed hardware can get expensive on-demand —right-size the instances, buy Savings Plans once usage is predictable, and put billing alerts in from day one. On security, the default posture is not production-grade: lock down security groups, enable GuardDuty and CloudTrail, and check that nothing is publicly exposed by accident.

• Cost: billing alarms, weekly Cost Explorer review, right-size after two weeks of real load
• Observability: CloudWatch dashboards and alarms matching the old system's, plus what you wished you'd had
• Security: least-privilege security groups, CloudTrail, GuardDuty, no public S3 or open ports by accident
• Reliability: test autoscaling and failover under load before you trust them, and only then decommission on-prem

A migration you can undo is a migration you can trust

The mental checklist is short. Can you see every dependency? Are you moving as-is first and modernizing later? Is the old system still authoritative and warm? Can you reverse the cutover in minutes, with a defined trigger and a named owner? If any answer is no, you're not ready to cut over —you're ready to plan more. The teams that migrate without the business noticing aren't braver. They just made the risky moment small, short, and reversible.