Data center exit to AWS or Azure
Cohash moves workloads out of owned or colocated data centers into AWS or Azure. We build the landing zone first, map application dependencies from network and process data, then group servers into waves with a cut-over and rollback plan for each. Every workload gets a decision: rehost, replatform onto managed services, or retire. The facility contract, hardware and licences are wound down once the last wave is stable.
- 01Landing zone before the first server
- 02Discovery and dependency mapping
- 03Disposition and wave design
- 04Replicate, test and cut over
- 05Optimize and exit
The story
Told without the client's name or anything that could identify them.
A manufacturer's infrastructure group faced a colocation renewal, a VMware quote under subscription pricing and the Windows Server 2016 and SQL Server 2016 support dates, all landing in the same planning cycle. Nobody could say which servers in the CMDB still served a live application, and backups, DR and patching rested on a small team that was already stretched. We built the landing zone as code first, then mapped dependencies from flow data and owner interviews before grouping servers into waves. Each wave replicated ahead, test cut over in an isolated network and went live with a rollback point, and the hardware and facility contract were wound down after the last wave settled.
why it was urgentThe exit question usually comes up when a lease renewal or hardware refresh lands in a year that already has dated problems. Broadcom stopped selling VMware perpetual licences on 11 December 2023. SQL Server 2016 left extended support on 14 July 2026, and Windows Server 2016 follows it on 12 January 2027.
- openThe colocation contract or hardware support renewal is due within 18 months and nobody wants to sign another term.
- recurringThe VMware renewal quote came back on subscription pricing, and finance wants to know what the alternative is.
- blockedNobody can say which of the servers in the CMDB still serve a live application.
- openBackups, DR and patching depend on a small infrastructure team that is already stretched.
The estate, before and after
Before: a colocated VMware estate with unknown dependencies
Applications ran on VMware in a colocation facility, on Windows Server 2016 and SQL Server 2016. Partner file drops, licence servers and hard-coded IPs tied systems together in ways the CMDB didn't record.
Read the diagram as text
- Business users → Windows Server 2016 VMs: app traffic
- Partner SFTP → Windows Server 2016 VMs: SFTP drops
- Windows Server 2016 VMs → SQL Server 2016: queries
- VMware cluster → Windows Server 2016 VMs: hosts
- Windows Server 2016 VMs → Licence and file servers: licence checks
- VMware cluster → Backup and DR: backups
- VMware cluster → CMDB: stale inventory
After: workloads in an AWS or Azure landing zone
Workloads run in a landing zone built as Terraform or Bicep, reached over Direct Connect, ExpressRoute or VPN while waves were in flight. Identity is federated, activity is logged to CloudTrail or the Azure activity log, and budgets track spend per workload.
Read the diagram as text
- Business users → Direct Connect or ExpressRoute: app traffic
- Partner SFTP → Rehosted servers: SFTP
- Direct Connect or ExpressRoute → Rehosted servers: private routing
- Identity federation → Landing zone: federated sign-in
- Rehosted servers → Managed databases: queries
- Landing zone → Activity logging: audit events
- Rehosted servers → Budgets and tags: usage and tags
How we run it, phase by phase.
5 phases take you from On-premises or colocation data center to AWS or Azure landing zone. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Landing zone before the first server
We build the accounts or subscriptions, network hub, DNS, identity federation, logging and guardrails as code. The link back to the data center (Direct Connect, ExpressRoute or VPN) is sized for replication traffic, and for steady state after it.
- phase 02
Discovery and dependency mapping
Collect inventory, utilization and network flows from agents or flow logs for several weeks. Dependencies are confirmed with application owners, because a nightly batch job or a hard-coded IP rarely shows up in a short capture.
- phase 03
Disposition and wave design
We mark each workload rehost, replatform, refactor, repurchase or retire, and group systems that talk to each other into the same wave. Wave one is deliberately small and low-risk. Its real job is testing the runbook.
- phase 04
Replicate, test and cut over
Block-level replication runs ahead of every wave. We do test cut-overs in an isolated network first. The real cut-over changes DNS and firewall rules inside an agreed window, with a rollback point held.
- phase 05
Optimize and exit
Right-size instances on real utilization, buy reservations or savings plans only after usage settles, then decommission hardware, wipe disks with certificates and close the facility contract.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every workload has an owner and a disposition
We marked every workload in the inventory as rehost, replatform, refactor, repurchase or retire, and named an owner for it. So nothing moved, or stayed, by default.
- result 02
The landing zone is code with guardrails
Everything foundational is in Terraform or Bicep now: accounts or subscriptions, the network hub, DNS, identity federation, logging. Changes go through review.
- result 03
Each wave had a tested cut-over and rollback
Chatty tiers moved together in the same wave. We ran test cut-overs in an isolated network, and the real cut-over changed DNS and firewall rules inside an agreed window, with a rollback point held.
- result 04
Cloud spend is tagged and sized on real usage
Tagging and budgets ran from the first wave, instances were right-sized on measured utilization, and reservations or savings plans were bought only after usage settled.
- result 05
The facility closed with a paper trail
Hardware was decommissioned and disks wiped with certificates. The decommission record covers servers, storage and the facility contract.
Risks we plan for
-
Hidden dependencies
Licence servers, file shares, mainframe links and partner SFTP endpoints break quietly after cut-over. Flow data plus owner interviews catch most of them before the wave, not after.
-
Licence surprises
Windows, SQL Server, Oracle and some ISV licences come with their own rules for shared cloud hardware. We check each one before choosing instance types. A dedicated host requirement changes the whole cost model.
-
Latency for split applications
An app in the cloud talking to a database still in the data center can slow to a crawl. We keep chatty tiers together in the same wave.
-
Cost drift after the move
Lift-and-shift servers sized for peak on-premises load keep running at that size. Tagging, budgets and a right-sizing review are part of the plan from wave one.
Where AI helps, and where it needs guardrails
On VMware and bare-metal moves, AWS Transform uses agents for discovery, wave planning and network conversion. To us what they produce is a draft, and we check it against flow logs and owners. Any agent or MCP server we give cloud credentials to during the migration runs under a role scoped to the landing zone, and its actions are logged to CloudTrail or the Azure activity log.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- design01
Landing zone as Terraform or Bicep, with guardrails and logging in place
yours to keep - inventory02
Application inventory with a disposition and an owner per workload
yours to keep - runbook03
Dependency map and wave plan with cut-over windows
yours to keep - runbook04
Cut-over and rollback runbook per wave
yours to keep - document05
Decommission record for servers, storage and facility contracts
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Landing zone
- The base cloud setup that workloads move into: accounts, network layout, identity and security rules, built before migration waves start.in context →
- 02Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
- 03Runbook
- A step-by-step procedure, written down, for an operational job such as a cutover. An on-call engineer should be able to follow it.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01AWS or Azure?
That depends on where your licences, identity and skills already are. A big Microsoft estate with Entra ID and SQL Server often lands more cheaply in Azure. Teams with AWS skills, or mostly Linux workloads, often prefer AWS. We price both against your real inventory, and some clients end up using both.
02How long does a data center exit take?
It depends on server count, how many applications need more than a rehost, and how often the business allows cut-over windows. The landing zone and discovery set the pace for everything after, so we give a dated wave plan once discovery is done.
03Should we refactor while we move?
Only where it pays for itself. Most servers rehost first and get modernized later. Databases and systems with a dated end of support are the usual exceptions, because moving them twice costs more.
04Do you run the cloud estate after the exit?
Yes. We run cloud management, which covers patching, cost reviews and on-call support. Or your team takes it over from us with the runbooks and the code.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case study0ff43b43 - 01VMware blog: End of availability of perpetual licensing (22 Jan 2024)blogs.vmware.com ↗
- 02Microsoft Lifecycle: SQL Server 2016learn.microsoft.com ↗
- 03Microsoft Lifecycle: Windows Server 2016learn.microsoft.com ↗
- 04AWS Transformaws.amazon.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it