How to migrate from on-premise to AWS without the drama

Moving out of your own data centre onto AWS is a sequencing problem wearing a technical costume, every tool you need already exists and works. Migrations fail on undiscovered dependencies, network surprises, and rushed cutovers, so here is the sequence that keeps all three boring.

Phase 1, Discover before you design

You can’t move what you can’t see, and every estate contains servers nobody remembers provisioning. Before touching AWS, build a real inventory:

• Every server, its specs, and its OS, CPU, RAM, disk, and OS version. Flag anything end-of-life (Windows Server 2012, CentOS 7): it still migrates, but it constrains your options and should be on the modernization list.
• Dependencies, what talks to what, on which ports. This is the step teams skip and regret at 2 a.m. Run an agent-based discovery tool (AWS Application Discovery Service, or a third-party equivalent) against live traffic for at least two weeks, long enough to catch the weekly batch job and the reporting query nobody documented.
• Data volumes and change rates, per database and file share, so you can size the network link and choose dump-and-restore vs continuous replication per system.
• Licensing, Windows and SQL Server licences are real money in the cloud; BYOL vs license-included changes the bill by thousands per year on a modest fleet.
• Owners and windows, who signs off on each app, and when it’s allowed to move.

The output is a portfolio you can assign a strategy to per application (rehost, replatform, retire, the 6 Rs) and group into migration waves. You will usually retire 10-20% of the inventory outright, which is the cheapest migration there is.

Phase 2, Build the landing zone and the network path

Stand up AWS properly before workloads arrive: a landing zone with separate accounts, SSO, guardrails, and centralized logging. That guide covers the structure; what bites on-premise migrations specifically is the network.

Two rules first:

• Give your VPC IP ranges that do not overlap your on-prem network, an overlap breaks routing between the two environments, and re-IPing either side mid-migration is a project of its own.
• Lay out public and private subnets across at least two availability zones, with a load balancer tier in front of anything internet-facing. Databases and app servers live in private subnets.

Then choose the on-prem-to-AWS link:

	Site-to-site VPN	Direct Connect
Time to provision	Hours	Weeks to months
Cost	~$36/mo per connection + data	~$220/mo for a 1 Gbps port, plus facility/partner fees
Bandwidth	~1.25 Gbps per tunnel, best-effort	1-100 Gbps, dedicated
Latency	Public internet, variable	Private path, consistent
Right when	Most migrations; ongoing hybrid access	Sustained large transfers, latency-sensitive hybrid apps, long-term hybrid

Default to the VPN. Direct Connect is the right call when the numbers say so, and if they do, order it during discovery, because its lead time is the longest item on the whole plan. For one-time bulk moves that would take weeks over your link (10 TB over 100 Mbps is ~10 days of saturation), a Snowball device is often faster than either.

Phase 3, Migrate in waves, never big-bang

Move one wave at a time, starting with something low-risk and self-contained, an internal tool, a staging environment, so your first cutover teaches lessons on a system that can afford them. The AWS toolset maps cleanly to workload type:

Workload	Tool	How it works
Whole servers (rehost)	AWS MGN	Continuous block-level replication of the source machine; test-launch in AWS while the source keeps serving. Free for 90 days per server.
Databases	AWS DMS	Full load, then change-data-capture keeps the target current until cutover, details in the database migration guide
Bulk file data	AWS DataSync	Scheduled, verified transfer into S3 object storage, EFS, or FSx (~$0.0125/GB)
Portfolio tracking	Migration Hub	One dashboard across all of the above

Each wave runs the same loop: replicate → test-launch → validate → cut over → observe. The test launch is the payoff of MGN’s design, you boot a full copy of the wave in AWS, point a test client at it, and find the hardcoded IP or missing driver on a Tuesday afternoon instead of during the window.

Two upgrades worth taking mid-flight: move self-managed databases to RDS (the classic small-effort, big-payoff replatform), and let static file servers become S3. Resist bigger rewrites, that’s a separate project with its own tradeoff analysis.

Phase 4, Cut over via DNS

For each wave, once the AWS copy is validated and replication lag is near zero:

1. T-48h: lower DNS TTLs to 60 seconds. The old TTL (often an hour or a day) has to expire from resolvers worldwide first, check the whole CNAME chain, not just the apex.
2. Pick the lowest-traffic window and announce it.
3. Stop writes on the source (maintenance mode), let replication drain to zero.
4. Run validation, for databases, the row counts and checksums you baselined earlier.
5. Repoint DNS at the AWS load balancer.
6. Watch error rates, latency, and one business metric (logins, orders) for the first hour. Keep the on-prem side answering, some clients ignore TTLs for days.

Rehearsed, this is 15-60 minutes per wave. For systems that can’t take even that, the zero-downtime playbook covers blue-green traffic shifting and reverse replication.

Phase 5, Validate, then decommission

Do not power off the old data centre on cutover day. Per wave:

• Keep the on-prem source running, read-only where possible, for at least a week as the rollback.
• Verify data integrity (row counts, checksums), functional paths that write, and performance against the baseline.
• Check the first real AWS bill against your estimate; right-size instances after a month of metrics, see estimating your cloud bill.

After a clean week: final snapshot of the source, archive it to S3, then decommission. The savings only start when the old hardware actually turns off, a half-emptied data centre costs nearly as much as a full one.

The failure modes, and their fixes

Mistake	Consequence	Fix
Skipping dependency discovery	Cutover breaks an undocumented integration	Agent-based discovery on live traffic, 2+ weeks
Overlapping IP ranges	VPN won’t route; emergency re-IP	Plan VPC CIDRs against on-prem before building
Ordering Direct Connect late	Weeks of idle waiting mid-project	Decide the link in discovery; default VPN
Big-bang cutover	One bad night takes everything down	Waves, lowest-risk first, test-launch each
Decommissioning too early	No rollback when the month-end job fails	Source stays alive read-only for a week+

FAQ

How long does an on-premise to AWS migration take?

For a small-to-mid estate (20-80 servers), plan 3-9 months end to end: 2-6 weeks of discovery and planning, 1-2 weeks standing up the landing zone and network, then migration waves of 2-4 weeks each. The timeline is set by dependency complexity, testing, and change-freeze windows, almost never by data-transfer speed. A single self-contained app can move in under a month.

Do we need AWS Direct Connect, or is a VPN enough?

A site-to-site VPN is enough for most migrations: it costs about $36/month per connection, is running in hours, and carries roughly 1.25 Gbps per tunnel. Direct Connect earns its cost when you need consistent low latency to on-prem, sustained large data flows, or a long-term hybrid setup, but a 1 Gbps port runs ~$220/month plus facility fees and takes weeks to months to provision, so order it in the discovery phase if you’ll need it.

What AWS tools handle the actual move?

AWS Application Migration Service (MGN) block-replicates entire servers for lift-and-shift and is free for 90 days per server. AWS Database Migration Service (DMS) does full-load plus continuous replication for databases. AWS DataSync moves bulk file data into S3, EFS, or FSx. Migration Hub tracks progress across the portfolio, and Application Discovery Service builds the dependency inventory.

How much downtime does the cutover cause?

With continuous replication (MGN/DMS) keeping the AWS copy seconds behind, each wave’s cutover is a low-traffic window of roughly 15-60 minutes: stop writes, let replication drain, validate, repoint DNS. Systems that can’t take even that use a blue-green pattern with gradual traffic shifting, more machinery, near-zero user impact.

---

The disciplined path above is straightforward to describe and genuinely hard to staff while also running the business. If you’d like a second set of eyes on your inventory, network plan, and wave sequence, or an engineer to run the migration with you, talk to a Webisoft cloud engineer. You’ll get an honest read on timeline and cost before committing to anything.