On-premise to AWS — the data-center exit, run for you and funded by AWS.

IWhy teams leave the data center now — the hardware-refresh cliff

Almost no one migrates a data center because a slide deck told them to. They migrate because a concrete cost event is bearing down — and AWS is cheaper than re-signing for another five years of metal.

The most common trigger is a hardware-refresh cliff. A storage array hits end-of-support, the hypervisor hosts are off warranty, the colocation contract renews, or the lease on the building itself is up. At that moment the CFO is staring at a six- or seven-figure capital outlay to buy the next generation of gear that will sit at 15–25% average utilization — the same dismal utilization every on-prem estate runs at, because you size for peak and pay for it 24/7/365.

AWS reframes that outlay. Instead of a capital purchase you depreciate over five years, you move to consumption-based operating expense — you pay for what runs, you switch it off at night for non-production, and you stop pre-buying headroom you will not use for three years. For a typical mid-market estate the line items that vanish are real: the refresh capex itself, the data-center power and cooling, the hardware maintenance contracts, the SAN licensing, and a meaningful slice of the staff hours spent racking, patching firmware, and chasing failed disks.

The second trigger is risk: a single facility with one power feed, aging UPS batteries, and a disaster-recovery plan that is really a spreadsheet and a prayer. Rebuilding that resilience on-prem means buying a second data center. On AWS it means deploying across Availability Zones and codifying DR with services like Elastic Disaster Recovery — capability you rent instead of build.

The honest caveat: AWS is not automatically cheaper if you forklift a badly-utilized estate as-is and never right-size. A naive lift-and-shift of over-provisioned VMs can cost more than the data center for the first few months. The savings come from right-sizing during discovery, switching off idle capacity, and committing to Savings Plans once the steady-state shape is known. That is exactly the work a MAP-funded partner does — and it is why the Assess phase pays for itself.

IIDiscovery: you cannot migrate what you have not mapped

Every credible data-center migration starts with an inventory and a dependency map. The deliverable is not a list of servers — it is a list of applications, what they talk to, and how busy they actually are.

AWS Application Discovery Service is the workhorse here. It runs two ways. The agentless collector ships as a VMware OVA that you deploy into vCenter; it reads VM inventory, configuration, and performance metrics without touching the guests — ideal for a first pass across a large vSphere estate. The agent-based path installs a lightweight Discovery Agent on each server (Linux or Windows, physical or virtual) and captures far richer data: running processes, established TCP connections, and per-process network traffic. That connection data is what produces the dependency graph.

The reason the dependency graph matters is wave planning. Applications are rarely self-contained — the web tier talks to an app tier, which talks to a database, which is also read by a nightly batch job on a server nobody remembers owning. If you migrate the database and leave the batch job behind, you have just opened a high-latency link across the internet between two halves of one system. Discovery surfaces those edges so you can group tightly-coupled components into the same migration wave and cut them over together.

Discovery also feeds the business case. Application Discovery Service exports utilization data into AWS Migration Hub, where you can model right-sized EC2 instance recommendations and a defensible TCO. This is where over-provisioning gets caught: the eight-vCPU VM running at 6% becomes a right-sized instance, and the as-is bill becomes a real bill. Plan on roughly two to four weeks of data collection for a mid-sized estate — long enough to capture month-end and weekend peaks, not just a quiet Tuesday.

The output of this phase is a portfolio sorted by the 7 Rs, with each application tagged for its path and its wave. Most teams find the bulk of the estate lands on Rehost or Replatform, a long tail gets Retired (servers running nothing of value — there are always more than expected), a few stay Retained on-prem for now, and a small, deliberate set is marked Refactor for later.

IIIThe three paths off a data center — and how to choose

Once the portfolio is sorted, every workload routes down one of three paths. Real estates use a blend; the skill is matching each application to the right one rather than forcing the whole data center through a single door.

The choice turns on two questions: are you a VMware shop, and does the workload have a hard constraint that keeps it close to the on-prem world (single-digit-millisecond latency to a factory floor, data-residency rules, a license tied to physical hardware)? Those two answers point at the three paths below.

IVWhich AWS service does which job

The migration toolchain is a small, well-defined set of services. Here is what each one is for, mapped to the phase of the data-center exit where you reach for it.

Everything is orchestrated through AWS Migration Hub, which gives a single dashboard of every server and application across the discovery, replication, and cutover phases — so the program lead can see wave status without logging into five consoles.

VNetworking: the link between two worlds during the migration

During a migration you run hybrid for weeks or months — half the system on AWS, half still on-prem. The network between them has to be fast, private, and predictable, or the dependency edges you mapped in discovery turn into latency complaints.

The default secure on-ramp is an AWS Site-to-Site VPN: IPsec tunnels from your on-prem firewall to a VPN gateway on AWS, encrypted over the public internet. It stands up in hours and is perfect for the early phases, for management traffic, and as a backup. Its limits are the public internet itself — variable latency and bandwidth capped around 1.25 Gbps per tunnel.

When you are moving terabytes and running latency-sensitive hybrid links, you provision AWS Direct Connect: a dedicated private circuit (1, 10, or 100 Gbps) from your data center into AWS that never touches the public internet. The catch is lead time — physical cross-connects take weeks to provision through a Direct Connect location, so this is something the partner orders early in Mobilize, not the week of cutover. A common pattern is Direct Connect for the bulk and steady-state traffic with a VPN as encrypted failover.

Tying it together is AWS Transit Gateway — a regional hub that connects your VPCs and your on-prem connections (both VPN and Direct Connect) through one routing point instead of a brittle mesh of peering connections. As you spin up landing-zone VPCs for production, shared services, and security tooling, Transit Gateway is what keeps the routing sane and lets you attach the on-prem side once and reach everything.

This all lands inside a properly structured landing zone — a multi-account AWS foundation with the network, identity, logging, and guardrails set up before any workload arrives. Migrating into a single flat account is a mistake you pay for later; a partner stands up the landing zone during Mobilize so the first wave has somewhere safe to land.

VIMoving the data: DataSync, Snowball, and the bandwidth math

Compute is portable; data has gravity. The largest single variable in a data-center exit is how long it takes to move the file shares, the object stores, and the databases — and whether the network can carry it in the window you have.

Do the arithmetic before you pick a tool. A 100 TB file share over a 1 Gbps link, even at a generous 80% sustained throughput, takes well over a week of continuous transfer — and that is before the migration traffic competes with your day-job traffic. Bandwidth, not cleverness, is usually the constraint.

For online transfer, AWS DataSync is the right tool for file and object data. It is a managed agent that moves data from NFS, SMB, and HDFS sources into S3, EFS, or FSx, with built-in encryption, integrity verification, scheduling, and incremental sync so you can pre-seed once and then top up the delta right before cutover. DataSync saturates the link you give it and handles the retry/verification work you would otherwise script by hand.

When the dataset is large enough that the network would take weeks — or when you simply do not have the bandwidth to spare — you ship it physically with AWS Snowball Edge. AWS sends a ruggedized, encrypted appliance; you copy data onto it on the local network at LAN speed, ship it back, and AWS loads it into S3. For multi-hundred-terabyte and petabyte moves, the express-shipping latency of a physical box beats the wire. A frequent hybrid pattern is Snowball for the cold bulk and DataSync for the warm delta and the final catch-up.

Databases get their own treatment via AWS Database Migration Service (DMS). DMS performs a full load and then switches to ongoing change-data-capture, replicating live transactions from the source so the target stays in sync while the application keeps running — that continuous replication is what shrinks the cutover window from days to minutes. For heterogeneous moves (for example consolidating an expensive Oracle estate onto Aurora PostgreSQL), the Schema Conversion Tool converts schema and stored code first; the heterogeneous conversion is the genuinely hard part and the line item most worth a specialist.

VIIDR and compliance: the upgrade most teams undersell

Leaving the data center is also the moment you fix the disaster-recovery story you have been quietly worried about, and the moment the compliance posture either gets easier or gets harder. Plan both deliberately.

On-prem DR usually means a second site you half-built, tape you hope restores, or an RTO measured in days. On AWS, AWS Elastic Disaster Recovery (DRS) continuously replicates your servers into a low-cost staging area in another Availability Zone or Region and lets you fail over in minutes and fail back when the incident clears. Spreading production across multiple AZs turns single-facility risk into something you configure rather than something you fear. Pair that with codified backups and you have replaced the spreadsheet-and-a-prayer plan with a tested one.

Compliance can move either direction. AWS inherits and certifies the physical and infrastructure layer — SOC 2, ISO 27001, PCI DSS, HIPAA-eligible services, and regional frameworks — which removes a large chunk of the audit surface you used to own when you ran the building. But the shared-responsibility model is real: AWS secures the cloud, you secure what you put in it. Misconfigured S3 buckets, over-broad IAM, and unencrypted volumes are your problem, not theirs.

Data residency is the constraint to nail early. If a regulator requires data to stay in-country, you choose the in-country Region (or, for the narrow cases that cannot use the public region yet, Outposts in your own facility) and you design the network so regulated data never leaves the boundary. This is exactly why discovery tags each application with its compliance constraints before any wave is scheduled — you do not want to find out a workload was in scope for a residency rule the night of its cutover.

A partner sets this up as guardrails in the landing zone — encryption-by-default, centralized logging to a dedicated account, config rules that flag drift, and identity wired to your existing directory — so the estate lands compliant rather than getting retrofitted after an auditor finds the gaps.

VIIICutover and the MAP-funded, done-for-you path

The cutover is the part everyone fears and the part good preparation makes boring. By the time you flip traffic, the data has been replicating for weeks and the target has already been tested. Then there is who pays for all of it.

A clean cutover runs to a runbook. You pick a low-traffic maintenance window. You stop the source application to freeze writes. MGN and DMS flush their final delta so the AWS side is byte-current. You launch the production instances from the replicated images, re-point DNS (with a low TTL set days earlier so the change propagates fast), and run a scripted smoke test against the new stack. If the validation passes, you open traffic; if it fails, you roll back to the still-intact source — which is why you never decommission on-prem until the AWS side has run clean in production for an agreed soak period.

Migrate in waves, not in one heroic weekend. The first wave is deliberately low-risk — internal tools, a non-critical app — so the team exercises the runbook, the network, and the rollback on something forgiving. Confidence and velocity build from there; the crown-jewel systems go in a later wave, once the path is proven.

Now the economics that make this an easy yes. The AWS Migration Acceleration Program (MAP) is structured in three phases — Assess (build the TCO and readiness case, typically free), Mobilize (stand up the landing zone, run a pilot wave), and Migrate & Modernize (production at scale). For qualifying migrations AWS provides funding and credits that scale with the size of the migration and are delivered through an AWS partner under the Partner Network. In practice that means the assessment costs you nothing and AWS credits a large share of the migration and modernization spend.

Honest framing: MAP funding applies to qualifying migrations — typically those with a meaningful committed AWS spend after the move — and the exact funding is scoped during Assess against your portfolio. Where it qualifies, the customer migrates at little-to-no cost because the partner is paid through MAP. Where it does not, CloudRoute still routes you to a vetted partner who runs the cutover and de-risks the project. Either way you are not hiring a migration team off cold outreach and hoping.

That is what CloudRoute does: you describe the data center once, we match you to a MAP-funded AWS partner with a real on-prem track record for your stack and region, the partner runs discovery through cutover, and the funding is arranged for you. Your job is to point at the dependency map and approve the waves.