On-Premises to AWS Migration: The 5 Paths, Costs and Checklist

On-premises to AWS migration has a vocabulary problem: AWS names seven strategies (the "7 Rs"), the consultants sell five phases, and the search results are either a 40-page enterprise whitepaper or a vendor pitch. Here is the version for a person with real servers in a real cupboard: the five paths that actually get used for a small or mid-sized migration, the AWS tool for each (Application Migration Service, Database Migration Service, VM Import, DataSync and Snowball, plain rebuilds), what each one costs (most have a free period), how long each takes, and the failure modes that catch people. Everything below is current as of September 2026, and it is written so you can pick a path for each server, not for the whole company at once.

The server under the counter

Jake's phone-repair shop has one physical server under the front counter. It runs the booking system (a Windows app with a SQL Server Express database), the customer photo archive (about 400 GB of images on a share), and a home-grown inventory spreadsheet that three people open at once and swear at. It's eight years old. The UPS beeps when the kettle is on.

"The IT guy says move it to AWS," Jake told Ethan. "I asked how. He said 'lift and shift'. I asked what that means. He said it's one of the seven Rs, and I stopped asking."

"The seven Rs are real," Ethan said. "AWS wrote them. But they're a vocabulary for a company with four hundred servers deciding what to do with each one. You have one server with three things on it. What you actually need is: which path each of those three things takes. The booking app takes one path. The database takes another. The photos take a third. And the spreadsheet should probably just die."

"That's four paths."

"Five, with the one where you rebuild instead of moving. That's the whole guide."

The 7 Rs in one table (so you can read what the consultant means)

AWS's migration guidance names seven strategies. You'll meet them in every meeting and every whitepaper, so here they are, with the one-line meaning and the plain-English version.

Two facts reframe the whole topic: the common strategies for large migrations are rehost, replatform, relocate and retire, and refactoring during a migration is the one to avoid, because it means modernizing the application while you move it. In other words: move first, improve later. That rule was written for 400-server migrations. It's even truer for one server, because you have no team to absorb two projects at once.

The five paths below are the 7 Rs collapsed to what a small migration actually does: rehost (path 1), replatform the database (path 2), move the data (path 3), rehost from an image (path 4), and rebuild (path 5). Retire and retain aren't paths; they're the decisions you make before you start, and the checklist starts with them.

Path 1: Rehost a server as-is with AWS Application Migration Service (MGN)

What it is. MGN (the console now calls it AWS Transform MGN) is AWS's primary rehost tool. You install a small agent on the source server (physical, virtual, or on another cloud). The agent replicates the server's disks, block by block, continuously, into a staging area in your AWS account: lightweight replication servers plus EBS volumes that hold a copy of your disks. When you're ready, you launch a test instance from that copy, check it, and then launch a cutover instance; the cutover window is typically minutes, because the data was already there. It replaced the older CloudEndure Migration and Server Migration Service.

What it supports. Windows Server and the common Linux distributions; IPv4 and IPv6; launching into standard Availability Zones or Local Zones; and, for bigger jobs, grouping servers into applications and applications into waves so you can cut over a batch at once.

What it costs. Each source server gets a free period of 2,160 hours, which is 90 days of continuous replication. After that, AWS charges per hour per server while replication continues. During the free period and after it, you pay for the AWS infrastructure MGN creates for you: the replication servers (small EC2 instances in the staging subnet), the staging EBS volumes, and any snapshots. When you launch test or cutover instances, those are ordinary EC2 and EBS charges. For a single small server, the staging cost during a 90-day migration is a few dollars a month; the trap is leaving replication running long after cutover, which quietly bills the staging area and, past day 90, the per-server hourly rate.

Setting up an MGN migration, step by step

1. Initialize MGN in the AWS Region you're migrating to (the console's first-run flow creates the IAM roles and a default replication template). Pick the region deliberately; our region and availability zone map explains what changes with the choice.
2. Set the replication template: the staging subnet (a private subnet in your VPC), the replication server instance type (the default is small and fine for most), EBS volume type, and encryption. Leave defaults unless you know why.
3. Install the agent on the source server. It needs outbound access on TCP 443 to the MGN endpoint and TCP 1500 to the replication servers. Firewalls that block 1500 are the number-one reason initial sync never starts.
4. Wait for initial sync. A 200 GB server on a 100 Mbps office line takes roughly five to six hours of pure transfer; the console shows lag. Replication then stays continuous, so the copy is always minutes behind.
5. Configure the launch template: instance type (MGN can right-size from the source's CPU/RAM), subnet, security groups, and whether to copy private IPs. This is where you decide the server's new network life.
6. Launch a test instance. It boots from a snapshot of the staged disks; the source keeps running and replicating. Log in, run the app, check services start. Terminate the test when done (it's billed as EC2 while it lives).
7. Cut over. Stop writes on the source (close the app, or put it in maintenance), wait for lag to reach zero, launch the cutover instance, repoint DNS or the users, and confirm.
8. Finalize cutover in the console. This is the step people forget: it stops replication, removes the staging resources, and stops the clock on the free period. Then, after a week of confidence, decommission the source.

The MGN failure modes, and what each one means

- Agent installed, no data flowing. Almost always port 1500 outbound to the staging subnet, or the source can't reach the AWS endpoint on 443. Check the firewall before anything else. - Replication stuck at "initial sync" for days. Bandwidth. Compute the number: disk size in GB × 8 ÷ line speed in Mbps ÷ 3,600 = hours. A 2 TB server on 20 Mbps is roughly nine days. That's when path 3 (Snowball) becomes the right choice for the bulk data. - Test instance boots but the app doesn't start. Static IPs baked into config files, licenses tied to hardware IDs, or drivers for hardware that doesn't exist on EC2. This is what the test instance is for; fix it there, not in cutover. - Windows: "password not available" or can't RDP after launch. Usually security-group or domain-join issues rather than MGN itself; our EC2 Windows password guide and EC2 connection timed-out guide cover both. - Bill keeps climbing after cutover. Replication was never finalized. Go back and finalize; check for orphaned staging volumes and snapshots.

"So the shop server goes in as a copy, and I test it before anyone uses it," Jake said.

"And the old one keeps running until you say otherwise," Ethan said. "You are never without a working server. That's the point of the whole design."

Path 2: Move the database with AWS Database Migration Service (DMS)

Why the database gets its own path. Rehosting copies a server's disks, database files included, and for a small app that's often enough: the SQL Server or MySQL that was on the box is now on an EC2 instance. But the reason most people migrate a database separately is to replatform it: SQL Server Express on a VM becomes Amazon RDS for SQL Server; MySQL on a box becomes RDS for MySQL or Aurora. You stop patching, backing up and worrying, and this is the textbook replatform move. Our RDS explainer and RDS vs Aurora pricing comparison cover the target side.

What DMS does. AWS Database Migration Service reads from a source database and writes to a target, either as a one-time full load, a full load plus ongoing change capture (so the source can stay live until cutover), or change capture only. The source and target can be the same engine (homogeneous, e.g. MySQL → RDS MySQL) or different (heterogeneous, e.g. SQL Server → Aurora PostgreSQL). For heterogeneous moves, DMS Schema Conversion converts the schema and code objects first and reports what it couldn't convert.

What it costs, honestly. Three separate things: - DMS Schema Conversion is free; you pay only for the S3 storage it uses. - Replication instances (dms.t3.micro up to r-class) are billed hourly while they exist; burstable ones include 50 GB of storage, compute-optimized 100 GB. DMS Serverless bills per DCU-hour (one DCU is 2 GB of RAM) only while the migration runs. Homogeneous data migrations have no instance or storage charge, only an hourly service fee during the migration. - The free tier changed. Before July 15, 2025, DMS gave 750 hours a month of a single-AZ dms.t3.micro for a year. Accounts after that date get $100 in DMS credits (with optional extra credits), valid up to 12 months, instead. Either way a small migration fits inside the free allowance.

A small database migration, in order

1. Create the target first. An RDS instance of the right engine, sized modestly (db.t4g.micro or small for a shop), in a private subnet, with a security group that allows the DMS replication instance in. Our guide to RDS "could not connect" timeouts is the checklist for that security group.
2. If the engine is changing, run DMS Schema Conversion against the source. Read the assessment report. Anything it marks as "manual" (stored procedures, triggers, engine-specific functions) is work you do before, not after.
3. Create a replication instance (or a serverless replication), in the same VPC as the target, with network reach to the source (VPN, Direct Connect, or a public endpoint with a tightly restricted security group; the last is fine for a one-off if you lock it to your office IP).
4. Define the source and target endpoints and test both connections from the console. Most "DMS doesn't work" is one of these two tests failing.
5. Create the migration task: full load + CDC if the app must stay live during the move; full load only if you can take it offline for the load. Enable validation so DMS compares row counts and data after the load.
6. Run it, then watch the CDC latency fall to near zero. That's your window: stop the app, wait for latency 0, repoint the app's connection string at RDS, start the app.
7. Stop the task and delete the replication instance. It's billed by the hour whether or not it's doing anything.

Path 3: Move the files with DataSync, or ship them with Snowball

Jake's 400 GB photo archive is the piece that isn't a "server" in any interesting sense. It's a pile of files that users open from a share. Two paths, and the choice is arithmetic.

AWS DataSync (over the network). An agent (a VM you run on-site, or an EC2 instance) reads from your NFS or SMB share and writes to S3, EFS or FSx. It handles verification, resumes after interruptions, and can run on a schedule so the copy stays current until cutover. The cost is a per-gigabyte transfer fee that is small next to the time it saves, plus the storage at the destination.

AWS Snowball (ship a device). AWS mails you a ruggedized storage device; you copy data onto it locally at disk speed, ship it back, and AWS loads it into S3. It's the answer when the network makes DataSync impractical. The arithmetic AWS uses is simple: if the transfer would take more than about a week over your line, a device is faster. On a 20 Mbps office uplink, 400 GB is about 45 hours; 4 TB is about three weeks. Under the first, use DataSync. Over the second, Snowball.

Where the files land. For an archive that users browse occasionally, S3 (our S3 explainer) with a lifecycle rule to move old photos to a cheaper class (the storage-class decision). For a share that Windows PCs must keep mounting as a drive letter, FSx for Windows File Server (explainer), which speaks SMB and joins Active Directory. For Linux servers that need a shared filesystem, EFS. The object vs block vs file guide is the one-page decider.

The failure mode nobody mentions: permissions. Windows shares carry NTFS permissions; S3 doesn't. If users need "only the front desk can see this folder", the destination is FSx (which keeps NTFS ACLs) or a rethink, not S3. Decide this before the copy, because it decides the destination.

Path 4: You already have a VM image (VM Import/Export)

If the on-premises server is already a virtual machine (VMware, Hyper-V, or VirtualBox), there is a shorter road than installing an agent: export the VM as a VMDK, VHD/VHDX or OVA, upload it to S3, and use VM Import/Export to turn it into an AMI you can launch on EC2. It sits alongside MGN as the other rehost tool.

When it's the better path. A handful of VMs; you can tolerate the downtime of "export, upload, import, launch" (hours to a day); and the VMs are plain (supported OS, standard drivers, no exotic disk layouts). It's also the right tool for a VM that's been powered off for a while, since MGN needs a running server to install its agent on.

When MGN wins. Anything that must keep running during the move (MGN replicates continuously; VM Import copies a snapshot), anything big (uploading a 500 GB VMDK from an office is the same bandwidth problem as path 3), and anything you want to test-launch repeatedly before cutover.

The steps, briefly. Export the VM (shut it down first). Upload the image to an S3 bucket in the target region. Create the vmimport service role with the permissions AWS's guide lists. Run aws ec2 import-image pointing at the file; wait for the task to reach completed (minutes to hours). Launch an instance from the new AMI. If the import fails, the error message almost always names the cause: an unsupported OS version, a disk that isn't the boot disk listed first, or a missing role permission; our AWS CLI credential errors guide covers the CLI side.

Cost. VM Import/Export itself is free; you pay for the S3 storage of the image while it's there and for the EC2/EBS you launch. Delete the uploaded image file from S3 when the AMI exists.

Path 5: Don't migrate it. Rebuild it on managed services.

Some things should not be lifted. Jake's inventory spreadsheet that three people open at once is the textbook case: it's not a workload, it's a problem. Rebuilding it as a small web app on managed services (a form in front of a database) is less work than making Excel-on-a-share behave across the internet, and it's the only path that fixes the actual complaint.

The candidates for rebuild:

- Apps whose only job is a form and a table. Rebuild on RDS plus a small container or Lambda. Our first real AWS project is exactly this shape, for $0. - Scheduled scripts on a server that exists only to run them. Move the script to Lambda (what Lambda is) on an EventBridge schedule; retire the server. - File shares whose real purpose is "send a customer a file". Presigned S3 links (how they work) replace the share and the VPN. - Email relays, DNS, small internal websites. SES, Route 53, S3 static hosting behind CloudFront (your own domain with HTTPS on AWS).

The rule, again, from AWS: do this after the rest is migrated, unless the app is small enough that rebuilding is a weekend. Two projects at once (moving and rewriting) is how migrations stall. The exception is the app that's so broken that moving it as-is just moves the breakage; the spreadsheet is one of those.

The planning tools AWS gives you for free (and when one server doesn't need them)

Before the five paths, AWS offers a layer of assessment tools. They cost nothing, and for more than about ten servers they're worth the setup. For Jake's one box they're overkill, but you should know what the consultant means when they name them.

- AWS Migration Hub is the dashboard. It tracks the status of every server and application across the migration tools (MGN, DMS, the discovery tools) in one place, in a home Region you choose once. It also holds the Strategy Recommendations feature, which looks at discovered servers and suggests an R for each (rehost, replatform, and so on) with a confidence rating. It's free; the tools it tracks have their own prices. - AWS Application Discovery Service collects the inventory: an agent on each server (or an agentless connector for VMware) reports CPU, memory, disk, network connections and running processes over a few weeks. That's the data behind the "zombie" (under 5% utilization) and "idle" (5-20%) labels AWS uses to find candidates to retire, and behind the dependency maps that tell you which servers talk to which, so you cut them over together. Free; the data lands in Migration Hub. - AWS Migration Evaluator (formerly TSO Logic) produces the business case: a projected AWS bill versus your current cost, from the same discovery data. It's the document finance asks for. Free, but it's a program you apply to rather than a button. - AWS Pricing Calculator is what you use instead, for a small migration: price a t4g.small, a db.t4g.micro, 500 GB of S3 and FSx's smallest configuration, and you have the "after" number in ten minutes. - Migration Acceleration Program (MAP) is AWS's funding program for larger migrations: credits and partner funding in exchange for a committed migration through an AWS partner. It has minimum sizes; a shop is below them. It's worth knowing the name so you understand why the consultant keeps saying "MAP-eligible".

The honest rule for a small migration. Under ten servers: a spreadsheet inventory, the Pricing Calculator, and the decision table below. Ten to a hundred: Application Discovery Service for two weeks, then Migration Hub to track waves. More than that: you are the company the whitepapers were written for, and Migration Evaluator and MAP exist for you.

"So I can skip all of that," Jake said.

"You can skip the tools," Ethan said. "You can't skip the inventory. Every migration that went badly, at any size, skipped the inventory."

Which path for which thing: the decision table

Jake's three things through the table: the booking app → path 1 (MGN, then path 2 for its SQL Server Express into RDS when comfortable; or native restore, since it's small). The photo archive → path 3 (DataSync over a weekend into FSx for Windows, because the front-desk folder permissions matter). The spreadsheet → path 5, rebuilt as a form; or, honestly, retired in favor of the booking app's own inventory feature, which nobody had turned on.

"So one server becomes three different jobs," Jake said.

"One server was three different jobs," Ethan said. "It just had one power cable."

The part every guide skips: how on-prem reaches AWS during the move

Paths 1, 2 and 3 all replicate over a network connection between your site and your VPC. Three options, in order of how often a small migration uses them:

1. Public endpoints with tight security groups. MGN's agent talks to AWS over the public internet on 443 and 1500; DMS can reach a source on a public IP. Lock the security group to your office's fixed IP. Fine for a one-server, one-quarter migration.
2. AWS Site-to-Site VPN. An IPsec tunnel from your office router or firewall to a Virtual Private Gateway. Hourly charge per connection plus data out. Right when the migration takes months, when there are many servers, or when the source database can't be exposed publicly at all.
3. AWS Direct Connect. A dedicated line, ordered through a partner, weeks to provision. For terabytes a month or a permanent hybrid setup, not for a shop.

Two networking facts that bite: replication traffic into AWS is free (data in is free on all of AWS), and the VPC subnet MGN stages into must be able to reach the internet or an endpoint for the agents to talk to it; a private subnet with no route is the classic "agent installed, nothing happens". Our internet gateway vs NAT gateway guide and VPC subnet public vs private explain the two pieces you'll touch.

What the migration itself costs (and what the shop pays after)

During the migration (say 60 days, one server, one database, 400 GB of files):

After the migration, the bill is the normal AWS bill, and that is where a shop should focus. A t4g.small instance, an RDS db.t4g.micro, FSx's smallest configuration and a domain add up to a real monthly number that the old server under the counter didn't have (it had a purchase price, electricity and the UPS that beeps). Three habits make it predictable: a three-layer billing alert on day one, a look at the ten most common surprise charges before cutover (idle load balancers and forgotten snapshots are migration specialities), and, after three months of steady usage, a look at Reserved Instances and Savings Plans for the parts that are clearly permanent.

The on-prem to AWS migration checklist, in order

This is the sequence, from "we should move" to "the old server is in the skip". Each step names the path it feeds.

1. Inventory. List every application, its server, its database, its data size, who uses it, and when it was last used. For more than a handful of servers, AWS Application Discovery Service and Migration Hub collect this automatically; for Jake's one box, a spreadsheet.
2. Retire and retain first. Anything unused for 90 days: retire (archive its data, turn it off). Anything with a hardware or regulatory dependency: retain. Everything left is the migration.
3. Assign a path to each item using the decision table. Write it down next to each row.
4. Set up the AWS account properly: an IAM admin user instead of root (why), MFA, a budget, CloudTrail on. Pick the region.
5. Build the landing zone: one VPC, public and private subnets, a security group per role. Keep it boring.
6. Move the data first (path 3). It takes the longest and it can run while you do everything else. Keep a final sync for cutover day.
7. Rehost the servers (path 1 or 4). Install agents; let replication run; launch test instances; fix what the test reveals (static IPs, licenses, drivers).
8. Migrate the databases (path 2) into RDS if you're replatforming, or leave them on the rehosted server for now and replatform in a later quarter.
9. Cut over, one workload at a time, starting with the least important. Stop writes, final sync, launch cutover, repoint DNS/users, verify.
10. Finalize and clean up. Finalize MGN cutovers (stops replication and billing), delete DMS instances, delete test instances, delete uploaded images from S3, check for orphaned volumes and snapshots.
11. Run both for a week. Keep the old server powered but idle. If nothing comes back, wipe and dispose.
12. Modernize, later. Now the rebuilds (path 5), the container moves, the Graviton switch. One at a time, on a schedule, with the migration already behind you.

On-premises to AWS migration: the questions people search

What are the steps to migrate from on-premises to AWS?

Inventory everything; retire what's unused and retain what can't move; assign a path to each item (rehost with MGN, replatform the database with DMS or native restore, move files with DataSync or Snowball, import existing VM images, or rebuild small apps on managed services); set up the account and VPC; move the data first; rehost and test; migrate databases; cut over one workload at a time; finalize and clean up; modernize afterwards. The full checklist is above.

What is the AWS Application Migration Service (MGN)?

AWS's primary rehost ("lift and shift") tool. An agent on the source server replicates its disks continuously to a staging area in your account; you launch test instances from the copy, then a cutover instance, with a cutover window of minutes. It supports Windows Server and common Linux distributions from physical, virtual or other-cloud sources, and replaced CloudEndure Migration and Server Migration Service.

Is AWS migration free?

Partly. MGN is free for 2,160 hours (90 days) of replication per source server, then billed hourly per server; you pay for the small staging infrastructure throughout. DMS Schema Conversion is free; DMS replication instances are billed hourly, with $100 in credits for new accounts. VM Import/Export is free. Data transfer into AWS is free. DataSync charges per gigabyte. The instances you launch are normal EC2/EBS charges.

What are the 7 Rs of AWS migration?

Retire, retain, rehost, relocate, repurchase, replatform, and refactor (re-architect). Rehost, replatform, relocate and retire are the common strategies for large migrations; refactoring during the migration itself is the one to avoid.

What is the difference between rehost and replatform?

Rehost moves the application as-is to EC2 without changes. Replatform moves it with some optimization, most commonly putting the database on RDS, moving a VM into a container, or switching to Graviton instances, without redesigning the application.

How do I migrate a SQL Server database to AWS?

For a small database, native backup and restore: back up to a .bak file, upload to S3, restore into RDS for SQL Server. For a live or large database, use AWS DMS with full load plus change data capture so the source stays online until cutover. If you're also changing engines (SQL Server to Aurora PostgreSQL), run DMS Schema Conversion first.

How long does a migration to AWS take?

For one server, one small database and a few hundred gigabytes of files: two to eight weeks of elapsed time, most of it waiting for replication and testing, with a few hours of actual downtime. Large migrations run in waves over months. The single biggest variable is your upload bandwidth.

How do I move large amounts of data to AWS?

Over the network with AWS DataSync for anything that transfers in under about a week on your line; with a Snowball device when it wouldn't. Data in is free; DataSync charges per gigabyte; Snowball is a per-job fee plus days on site.

What is AWS Migration Hub?

A console that tracks migration progress across tools (MGN, DMS, Application Discovery Service) in one place, with a home Region where the tracking data lives. Useful for many servers; unnecessary for one.

Can I migrate a VMware VM directly to AWS?

Yes, three ways: install the MGN agent inside the VM (keeps it running, minutes of cutover), export it and use VM Import/Export (simpler, but the VM is down while you export and import), or, for a whole VMware estate, relocate with VMware Cloud on AWS.

Should I migrate to EC2 or to containers/serverless?

Migrate to EC2 first if the application works today; that's rehost, and it's the right order for the migration itself. Move to containers or serverless afterwards, one application at a time, when you can see what actually needs it.

What is lift and shift in AWS?

Another name for rehost: copying servers to AWS without changing the applications. MGN and VM Import/Export are the tools. It's the fastest and lowest-risk way to move, and the standard first step before modernization.

What are common mistakes in on-prem to AWS migration?

Rewriting the app while moving it; leaving MGN replication running after cutover (bills the staging area and then the per-server rate); forgetting Windows share permissions when files land in S3; exposing a source database publicly without locking the security group; not testing the launched instance before cutover; and not setting a budget alert before the first instance launches.

How do I migrate Active Directory to AWS?

Usually you don't migrate it, you extend it: a VPN to AWS and a domain controller in the VPC, or AWS Managed Microsoft AD with a trust to your on-prem domain. FSx for Windows File Server and EC2 Windows instances then join the domain normally.

Do I need a VPN to migrate to AWS?

Not for a small migration. MGN's agent and DataSync talk to AWS over the public internet on encrypted connections, and DMS can reach a source on a public endpoint locked to your IP. A Site-to-Site VPN is worth it for a months-long migration, many servers, or a database that must never be public.

What happens to my licenses when I move to AWS?

Linux and open-source databases: nothing changes. Windows Server and SQL Server: use AWS's license-included instances (the license is in the hourly price) or bring your own where Microsoft's terms allow it (dedicated hosts for some cases). Check the specific product's terms before cutover; it is the most common late surprise.

Should I migrate to AWS or Azure for a Windows shop?

Both run Windows workloads well. Azure's Hybrid Benefit makes existing Windows Server and SQL Server licenses cheaper to reuse, and Entra ID integration is simpler for Microsoft 365 shops; AWS has the broader service catalog and the larger community. Our AWS vs Azure vs Google Cloud comparison puts the two side by side.

If you've been told to "migrate to AWS" and handed a whitepaper written for a company with a data center, please take one thing from this page: your server is three or four separate jobs, each with its own path and its own tool, and the safe order is data first, servers second, databases third, and improvements last. None of the tools costs anything to try, the source keeps running while you test, and the old box stays plugged in until you're sure. If a step here doesn't match what you see in the MGN or DMS console, tell me through the contact page; AWS renames and reorganizes these services often, and this page stays accurate because readers write in.

Revision note. Written September 26, 2026; the MGN free period, DMS free-tier change and Schema Conversion pricing are current as of that date, and the transfer-time figures are arithmetic on the line speeds shown. Next check: when AWS changes MGN's free period or per-server rate, DMS credits, or the DataSync/Snowball line-up. Start with the inventory; it is the one step every successful migration has in common.