Datacenter Exit Program Planning and Management
A datacenter or colocation exit with 50 to 1,000-plus workloads fails on sequencing, not on migration tooling — and the date is rarely negotiable: the lease or colocation contract ends, the hardware leaves vendor support, and per Microsoft's product lifecycle Windows Server 2016 leaves extended support on 12 January 2027 while SQL Server 2016 already left it on 14 July 2026. IT Partner runs the exit as a program: an Azure Migrate discovery baseline, application and dependency mapping into move groups, a wave design and cutover calendar worked back from your exit date, network readiness (ExpressRoute or site-to-site VPN sizing, Active Directory sites, DNS, an IP plan that does not overlap), landing-zone prerequisites, licensing and Azure Hybrid Benefit, a Microsoft partner-funding eligibility check, risk and rollback governance, a weekly program office, and coordination of the decommission and asset disposal at the end. The individual workload migrations — VMware, Hyper-V, physical, SQL Server — are quoted separately per wave, and network implementation and the physical teardown are their own engagements. Quoted per estate, fixed-price in writing before work begins, and you pay after you approve delivery; where the scope is still moving, program management can run time-and-materials at our standard published hourly rate of $175 instead. The core engagement runs about 12 weeks — planning through the first wave — and continues per wave until the last rack is out.
What this engagement is
Datacenter exits fail in predictable places, and almost none of them are inside the migration tool. An application server moves to Azure in week six while the license server it talks to every ninety seconds stays in the rack, and the application crawls across the VPN. The ExpressRoute circuit is ordered in week eight and the provider needs longer than that to deliver it, so the first three waves replicate over a gateway sized for email. Active Directory sites and subnets are never updated, so every new Azure VM authenticates against a domain controller on the wrong side of the WAN. DNS still resolves the old addresses. Firewall rules are copied instead of understood. And when the last workload finally lands, nobody owns the teardown — so the colocation invoice arrives for another quarter, and a cabinet of unsanitized disks goes to a recycler on a handshake. None of that is a technology problem. It is a sequencing, ownership and calendar problem, and it needs a program layer above the individual migrations. That layer is what this service is. It starts from evidence — our Azure Migrate discovery and assessment if you do not already have a trusted baseline, or your CMDB and hypervisor exports reconciled against what discovery actually finds — and turns the estate into move groups: applications, the servers under them and the observed dependencies between them, corroborated with the people who own each application. The move groups become waves; the waves become a cutover calendar worked back from the date you must be out, with the freeze windows, month-end closes and vendor lead times already on it. In parallel we make the destination ready before wave one needs it: the network path — an ExpressRoute circuit or a zone-redundant site-to-site VPN gateway sized from measured replication and steady-state traffic rather than a guess, Active Directory sites and subnets, DNS, an IP plan that does not overlap the datacenter you are leaving, firewall and routing rules; the Azure landing zone prerequisites the plan will name plainly if you lack them; and the licensing position — which Windows Server and SQL Server licenses carry Azure Hybrid Benefit, which servers need an Extended Security Updates bridge because they cannot move before their lifecycle date, and whether your estate plausibly qualifies for Microsoft's partner-delivered migration funding, assessed and pursued but never promised. Then we run it. A weekly program office with your IT lead, application owners and, where they exist, your colocation provider and network carrier: a single plan, a single risk-and-issue log, a readiness checklist every wave must pass before it is scheduled, a cutover runbook per wave with go/no-go criteria and a tested rollback, and a decision record for every deviation. The migrations themselves are executed wave by wave as separately quoted engagements — VMware to Azure, physical Windows Server to Azure, Hyper-V to Azure, SQL Server to Azure and its managed alternatives — by our engineers, by yours or by another vendor; the program layer is deliberately neutral about who turns the wrench, because a plan that only works if its author does the work is a sales document. Servers that should not move at all — latency-bound, license-bound, hardware-bound — are named as such and given a real destination: an Azure Local cluster where a small on-premises footprint has to survive, Azure Arc for what stays under management where it is, or retirement. The exit ends when the room is empty and the bills stop, not when the last VM boots in Azure. So the program closes with a decommission plan sequenced against your contract notice periods, a certificate of data destruction for every disk against a named standard, asset-disposal coordination with the vendor you choose, and a final reconciliation: every workload in the baseline accounted for as migrated, retired, or deliberately left behind with an owner. Microsoft's own charges — Azure consumption, replication after Microsoft's free window, ESU fees — are billed by Microsoft to you and are never inside our fee; we say so at every point where the calendar affects them.
Success criteria
What you receive
How the work unfolds
Scope is agreed in writing: which datacenters or colocations, which workloads, the exit date and every contract notice period behind it. The program office, steering group and log are stood up. If a trusted discovery baseline does not exist, the Azure Migrate appliance is deployed now so its collection window overlaps the planning work instead of delaying it; your CMDB and hypervisor exports are reconciled against what discovery finds.
Observed dependencies are grouped into application-level move groups and corroborated with application owners, because the tool sees connections and your people know what they mean. Each workload gets a disposition — Azure IaaS, PaaS, Azure Local, stay, or retire — and the servers that should not move are named early, while there is still time to decide what happens to them.
Connectivity is sized from measured data — replication throughput for the waves and steady-state traffic afterwards — and the ExpressRoute or VPN decision is made and ordered early, because provider lead times are the most common cause of a slipped wave one. Active Directory sites and subnets, DNS, the IP plan and firewall rules are designed per wave; the landing-zone prerequisites are stated and either confirmed present or scoped.
Your Windows Server and SQL Server license position is established from documents, Azure Hybrid Benefit is mapped to each wave, and any server that cannot leave before its Microsoft lifecycle date gets a dated Extended Security Updates bridge with a written exit. Microsoft partner-funding eligibility is assessed and, where it fits, the application is prepared.
Move groups become waves on a calendar worked back from the exit date, with freeze windows, month-end and seasonal peaks, vendor lead times and decommission notice periods on the same timeline. Each wave receives its readiness checklist, runbook, go/no-go criteria and rollback; each migration is quoted as its own engagement, by us or by whoever you choose.
The first wave — deliberately a low-risk, representative group — is cut over under the runbook, with the program office running weekly and the lessons folded into every later wave's plan. Replication windows are managed so servers do not sit replicating past Microsoft's free period.
Program management continues per wave under the terms the quote states, through the decommission sequence, data-destruction certification, asset disposal and the final baseline reconciliation. The program closes when the room is empty and the colocation or lease bills have stopped on the planned date — not when the last VM boots.
Prerequisites
Who does what
IT Partner
- Run the program office: the plan, the calendar, the single risk, issue and decision log, and the weekly steering update.
- Build and maintain the workload baseline, dependency map, move groups, wave plan and cutover calendar.
- Design network readiness and the landing-zone prerequisites per wave, and coordinate the carrier order and the landing-zone work so both exist before the wave that needs them.
- Establish the licensing position, map Azure Hybrid Benefit and any ESU bridge per wave, and assess and prepare Microsoft funding applications where the estate qualifies.
- Produce the readiness checklist, runbook, go/no-go criteria and rollback for every wave, and chair the go/no-go decision.
- Coordinate migration teams — ours, yours or third parties — vendors, carrier and colocation provider against the one calendar.
- Plan and coordinate the decommission, data-destruction certification and asset disposal, and reconcile the baseline at close.
- Say plainly when a workload should stay, be retired or move somewhere other than Azure, even when that earns us nothing.
Your team
- Own the exit date and the contract relationships with the colocation provider, carrier and hardware vendors, and sign the orders the plan calls for.
- Make application owners and an infrastructure lead available for dependency corroboration and the weekly program office.
- Provide discovery access and licensing documents, and decide on the discovery approach if a baseline does not exist.
- Make the go/no-go decision for each wave on the criteria agreed, and approve the migration quotes you choose to place — with us or with others.
- Fund Azure consumption, connectivity circuits, licensing and Extended Security Updates directly with Microsoft, your carrier and your vendors.
- Choose and contract the asset-disposal vendor, and confirm retention and legal-hold requirements before anything is powered off.
- Attend steering, decide escalations within the agreed window, and sign off wave and program closure.
What's not included
Limitations & technical notes
Frequently asked questions
How is this different from the Azure Migrate discovery and assessment?
The assessment measures: an appliance, two weeks of utilization and dependency data, a right-sized cost model and a wave recommendation. It answers 'what do we have and what would it cost in Azure'. This program answers 'how do we get out of the building by the date, in what order, with whom, and without an outage' — and then runs that plan week by week. The assessment is the best input to the program; if you do not already have a trusted baseline it runs first or in parallel, and nothing here re-does it.
We have 40 servers in one colocation. Do we need a program?
Probably not, and we will say so on the free discovery call. A single-site estate of a few dozen VMs on one hypervisor is usually a wave-planned migration — VMware, Hyper-V or physical to Azure — with its own plan, test migrations and cutovers, and that engagement already includes the sequencing a small estate needs. The program layer earns its fee when there are multiple sites or contracts, hundreds of workloads, several teams or vendors, a network build that has to land before wave one, and a date that cannot move.
Our lease ends in seven months. Is that enough time?
It depends less on the workload count than on lead times: connectivity delivery, landing-zone readiness, the discovery window, application-owner availability and your own freeze periods. Seven months is workable for many mid-size estates if wave one starts within the first quarter; it is not workable if the ExpressRoute order goes in during month four. The first two weeks produce a calendar that tells you honestly whether the date holds, what has to be true for it to hold, and which contract conversation to open now if it does not.
Should we use ExpressRoute or a site-to-site VPN?
For the migration itself the question is throughput and predictability: how much data has to replicate in how many weeks, and how much traffic will cross between the datacenter and Azure while applications are split across both. A zone-redundant VPN gateway on a current SKU is enough for many exits and can be up in days; an ExpressRoute circuit gives private, predictable bandwidth at higher capacities but carries a provider lead time and a monthly cost that continues after the exit — so the answer also depends on what stays connected afterwards. We size from measured traffic, recommend one, and order it early; the implementation is a separate engagement.
What about Active Directory and DNS?
They are the most common cause of a 'successful' migration that performs terribly. Azure address space must be defined as Active Directory sites and subnets so Azure VMs authenticate against nearby domain controllers — usually new ones built in Azure early rather than replicated ones. DNS has to be planned per wave so names resolve to the new addresses at cutover and nothing hard-codes the old ones. The IP plan must not overlap the datacenter you are leaving, or you lose the ability to run both sides during the transition. All three are designed before wave one and checked on every wave's readiness list.
Some servers run Windows Server 2016 or SQL Server 2016. Does the exit date interact with their support dates?
Yes, and the plan puts both on the same calendar. Per Microsoft's product lifecycle, SQL Server 2016 left extended support on 14 July 2026 and Windows Server 2016 leaves it on 12 January 2027. A server that migrates to Azure before its date is simply migrated; a server that cannot move in time gets a dated Extended Security Updates bridge — priced at Microsoft's current rules, which since April 2026 charge the same list price wherever the server runs — with the exit from ESU written into the wave plan. Where an in-place upgrade or a rebuild on Windows Server 2025 is the better answer for a server that is staying, the disposition register says so.
Can Microsoft help pay for this?
Sometimes. Microsoft operates partner-delivered funding programs for qualifying Azure migrations — currently consolidated under Azure Accelerate — whose eligibility, scope and amounts are Microsoft's decision, change by fiscal year and are never guaranteed. We assess honestly whether your estate fits, prepare the application if it does, and build the plan so it stands without it. Programs built on funding that then lapses are how exits stall halfway.
Who does the actual migrations?
Whoever you choose. Each wave is a separately quoted engagement; our engineers can run them, your team can, or another vendor can — the program office plans, gates and coordinates all three the same way. We price our own migrations as fixed, written per-wave quotes so comparison is easy, and we would obviously like the work; but the plan is written to survive our absence, because a plan that only works if its author executes it is not a plan.
What if some workloads should not go to Azure?
Then the disposition register says so, with reasons per workload. Real estates split: most workloads move cleanly, some need remediation first, some should be retired or bought as SaaS, and a few — latency-bound to equipment that stays, license-bound, or hardware-bound — need somewhere that is not a public-cloud VM. For those we name a real destination: an Azure Local cluster where a small on-premises footprint has to survive, a smaller colocation, or Azure Arc management for what stays where it is. The exit still completes; it just completes honestly.
How do you handle rollback and the risk of an outage?
Every wave has a runbook with go/no-go criteria agreed before the day, a test migration into an isolated network wherever the migration tooling supports it, a validation list against the baseline, and a rollback that has actually been walked through — the source stays intact until the wave is signed off. Cutovers are scheduled inside agreed windows and outside freezes; deviations go into the decision log rather than someone's memory. A wave that fails its readiness checklist does not get a date.
What does 'decommission coordination' actually mean?
It means the exit ends with the bills stopping, not with the last VM booting. We sequence the teardown against your contract notice periods, make sure backups and retention or legal holds are satisfied before anything is powered off, specify data-destruction certification against a named standard such as NIST SP 800-88 for every disk, coordinate the asset-disposal vendor you contract, and reconcile the baseline so every workload is accounted for. The hands-on work — de-racking, transport, destruction — is your team's or the vendor's; the accountability for it being complete is the program's.
How is it priced, and what does the 12 weeks cover?
Quoted per estate from the workload count, sites, wave count and program length — fixed-price in writing before work begins, and you pay after you approve delivery. The core 12 weeks covers mobilization and baseline through wave one under program control; the quote states how many further waves and weeks it includes, and later waves are added on the same terms. If the scope is genuinely still moving — the exit date is being negotiated, the workload count is unknown — program management can run time-and-materials at our standard published hourly rate of $175 instead, and we will tell you which model suits your situation. Microsoft's, your carrier's and your vendors' charges are never inside our fee.
Can we take the plan and run it ourselves?
Yes. The baseline, dependency map, wave plan, network design, governance pack and close-out plan are working documents delivered to you, and the Azure Migrate project lives in your subscription. Some clients take the 12-week planning phase and run the program office themselves; some keep us through the last wave. Both are legitimate, and the walkthrough at week 12 ends with a recommendation, not a close.