On-premise to AWS: the data-center exit, step by step.

IWhy teams leave the data center: the hardware-refresh cliff

Almost no one migrates a data center because a slide deck said so. They move because a cost event is coming, and renting AWS beats buying another five years of hardware.

The usual trigger is a refresh cliff. A storage array reaches end of support, the hypervisor hosts fall out of warranty, or the colocation contract renews. The CFO is looking at a large capital outlay for gear that will sit at low average utilization, because on-prem you size for peak and pay for it around the clock.

AWS turns that purchase into operating expense. You pay for what runs, switch non-production off at night and stop pre-buying headroom. The line items that go away are real: the refresh itself, power and cooling, hardware maintenance contracts, SAN licensing, and a good share of the hours spent racking servers and swapping disks.

The second trigger is risk: one facility, one power feed, and a disaster-recovery plan that has never been tested. Rebuilding that resilience on-prem means a second site. On AWS it means spreading across Availability Zones and using Elastic Disaster Recovery.

IIIs AWS cheaper than refreshing the hardware?

Often, but not automatically. Compare total cost of ownership, not the server price against an hourly rate.

The on-prem side has eight lines: hardware capex (amortized), data-center or colo space, power and cooling, network and bandwidth, the people who operate it, the over-provisioning you buy for peak, software licenses, and the next refresh. The AWS side is metered compute and storage, managed-service premiums, support, and data transfer out, which is the one line where cloud often loses.

Cloud wins clearly for variable, spiky or growing workloads, and wherever operational labor goes away. On-prem can still win for steady, heavy compute that runs flat out for years on hardware you already own.

Two things decide the result. First, right-size from measured utilization: lifting oversized VMs as-is can cost more than the data center for months. AWS Migration Evaluator and Application Discovery Service build the model from real usage. Second, include the one-time migration cost and the MAP funding that can offset part of it, so you can see when the cumulative cost crosses over. Model it with the funding and without it.

IIIDiscovery: you cannot migrate what you have not mapped

Every credible data-center migration starts with an inventory and a dependency map: the applications, what they talk to, and how busy they really are.

AWS Application Discovery Service runs two ways. The agentless collector is deployed into vCenter and reads VM inventory, configuration and performance without touching the guests: a good first pass across a vSphere estate. The Discovery Agent installs on each server (Linux or Windows, physical or virtual) and captures running processes and network connections. Those connections produce the dependency graph.

The graph drives wave planning. 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. Move the database and leave the batch job behind, and you have built a slow internet link through the middle of one system. Discovery shows those edges, so tightly coupled parts move in the same wave.

Discovery also feeds the business case: the data flows into AWS Migration Hub for right-sizing and the TCO model. Plan on two to four weeks of collection for a mid-sized estate, long enough to catch month-end peaks.

The output is a portfolio sorted by the 7 Rs. Most of the estate lands on rehost or replatform, a long tail gets retired, a few systems stay on-prem for now, and a small set is marked for refactoring later.

IVThe three paths off a data center

Each workload goes down one of three paths. Real estates use a blend; the skill is matching each application to the right one instead of forcing everything through one door.

Two questions decide it. Are you a VMware shop? And does the workload have a hard constraint that keeps it close to your building, such as very low latency to local equipment, data-residency rules or a license tied to physical hardware?

VWhich AWS service does which job

The migration toolchain is a small set of services. Here is what each one is for, by phase. AWS Migration Hub tracks every server and application across all of them.

VINetworking: the link between two worlds

During the migration you run hybrid for weeks or months. The link between the two sides has to be private, fast and predictable, or the dependencies you mapped turn into latency complaints.

Start with AWS Site-to-Site VPN: IPsec tunnels from your firewall to AWS over the internet. It is up in hours and fine for early phases and management traffic, but each tunnel tops out around 1.25 Gbps and latency varies.

For terabytes and latency-sensitive links, order AWS Direct Connect: a dedicated private circuit (1, 10 or 100 Gbps) that never touches the public internet. Cross-connects take weeks to provision, so the partner orders the circuit early in the project, not the week of cutover. A common pattern is Direct Connect for bulk and steady traffic, with the VPN as encrypted failover.

AWS Transit Gateway ties it together: one regional hub that connects your VPCs and both on-prem links through a single routing point. All of it lands in a multi-account landing zone built before the first workload arrives. See AWS landing zone.

VIIMoving the data: DataSync, the Data Transfer Terminal and the bandwidth math

Compute moves easily; data has gravity. How long the file shares, object stores and databases take to move often sets the schedule.

Do the math first. A 100 TB file share over a 1 Gbps link at 80% sustained throughput takes well over a week of continuous transfer, before it competes with daytime traffic. Bandwidth, not cleverness, is usually the constraint.

For online transfer, AWS DataSync moves file and object data (NFS, SMB, HDFS, self-managed object storage) into S3, EFS or FSx with encryption, integrity checks and incremental sync, so you seed once and top up the delta before cutover. AWS says a single DataSync task can use a full 10 Gbps link, and pairing it with a temporary Direct Connect hosted connection helps when bandwidth is short.

For offline transfer, Snowball Edge is closed to new customers. AWS now points to the AWS Data Transfer Terminal, a site where you bring your own storage devices and upload at high speed, or to partner offline-transfer services in AWS Marketplace.

Databases use AWS Database Migration Service (DMS): a full load, then change data capture that keeps the target in sync while the app runs. Engine changes, such as Oracle to Aurora PostgreSQL, also need the Schema Conversion Tool, and that conversion is the hard part. See Oracle to AWS.

VIIIDR and compliance: the upgrade teams undersell

Leaving the data center is also the moment to fix disaster recovery and to decide how compliance will work. Plan both on purpose.

On-prem DR is often a half-built second site or a restore nobody has tested. AWS Elastic Disaster Recovery (DRS) continuously replicates servers into a low-cost staging area in another Availability Zone or Region, so you can fail over in minutes and fail back when the incident clears. Spreading production across Availability Zones turns single-facility risk into a setting.

AWS certifies the physical and infrastructure layer (SOC 2, ISO 27001, PCI DSS, HIPAA-eligible services and regional frameworks), which removes part of the audit surface you owned when you ran the building. The shared-responsibility model still applies: misconfigured S3 buckets, broad IAM roles and unencrypted volumes are yours to prevent.

Pin down data residency early. If data must stay in-country, pick the in-country Region (or Outposts for the narrow cases that cannot use it) and design the network so regulated data stays inside the boundary. A partner sets this up as landing-zone guardrails: encryption by default, central logging, Config rules that flag drift and identity tied to your directory.

IXCutover, and who files the funding

Good preparation makes the cutover boring. By the time you switch traffic, the data has been replicating for weeks and the target has been tested.

A clean cutover runs to a runbook. Pick a low-traffic window. Stop the source app to freeze writes. Let MGN and DMS flush the final changes. Launch production from the replicated images, switch DNS (with a low TTL set days earlier) and run a scripted smoke test. If it passes, open traffic. If it fails, roll back to the untouched source, which is why you never decommission on-prem until the AWS side has run clean for an agreed soak period.

Migrate in waves, not one heroic weekend. Start with something forgiving, such as internal tools, so the team exercises the runbook, the network and the rollback. The critical systems go in a later wave, once the path is proven.

MAP (the AWS Migration Acceleration Program) has three phases: Assess (readiness and a TCO model), Mobilize (landing zone and a pilot wave) and Migrate and Modernize (production at scale). AWS describes it as tools, training, partner expertise and financial investments that offset initial migration costs, and it runs MAP tracks for VMware, Microsoft and SAP workloads. Your matched partner files the MAP request when the migration qualifies, and AWS decides the amount. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves. Partner funding programs reach about $1M, but that tier is for enterprises such as banks, hospitals and municipalities, not startups.

If the migration does not qualify, a vetted partner still runs and de-risks the cutover, at its normal rates. CloudRoute is the match: you describe the data center once, and we introduce a vetted AWS partner with on-prem experience for your stack and region. CloudRoute is free for you. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.