Exiting a colo: what the last three years of a datacenter cost against cloud

The invoice that ends a colo tenancy is not the one the finance team sees

A datacenter exit starts as a facilities decision and becomes a five-year total cost comparison. The monthly rack fee is the visible line, but the number that decides the move is the sum of rack space, cross-connects, power draw, hardware refresh and the migration project itself, set against what the same estate costs to run in a hyperscaler. Teams that compare only the hosting invoice against a cloud estimate usually find the cloud looks expensive, because the refresh cycle and the project cost sit outside the comparison on one side and inside it on the other.

The refresh cycle is where the arithmetic turns. A three-year hardware replacement on servers, storage and network gear is a capital event that a colo tenancy defers but does not remove, and it lands again inside any five-year window. Cloud spend replaces that capital event with an operating line, which is why the comparison has to run over the same period on both sides. A colo that looks cheaper in year one can lose by year four once the refresh, the power bill and the cross-connect fees are counted together.

Neither AWS nor Microsoft publishes a per-workload migration price on the pages here. AWS describes AWS Transform as automating infrastructure migration across VMware, bare metal and hybrid environments, and Microsoft describes Azure Migrate as discovering infrastructure, applications and data and assessing them against the six R options. Both are tooling descriptions, not quotes. The migration project cost has to come from the vendor or a partner as a scoped number before the business case closes, and a team that skips that step is comparing a known colo cost against an unknown cloud one.

AWS and Azure sell the move, not the number

AWS positions AWS Transform as a collaborative workbench that automates infrastructure migration for workloads across VMware, bare metal and hybrid environments, and claims Windows, mainframe and VMware applications modernize up to five times faster with agentic automation of analysis, planning, documentation and transformation tasks. The page also claims the equivalent of 1,305 developer years of work saved, without stating the baseline or the period those hours cover. That figure is a vendor claim about effort avoided, not a price, and it should not be entered into a total cost model as a saving.

Microsoft's equivalent is Azure Migrate, which the page describes as automatically discovering infrastructure, applications and data, understanding dependencies and readiness, and using assessments and the six R options to align workloads with the right treatment. Azure Copilot adds an agentic layer that orchestrates the migration journey and coordinates first and third-party tools. Microsoft also states that Azure Migrate is a non-regional service with no dependency on a specific Azure region, which matters for a team that has to keep data in a named jurisdiction after leaving a colo.

Both vendors publish migration tooling and neither publishes a migration price on these pages. The honest reading is that the tooling reduces the labour inside the project but does not let a buyer skip the quote. Ask AWS for a scoped price on the VMware and bare metal estate and ask Microsoft for the same on the Azure Migrate assessment plus the execution phase, then compare those two numbers against the colo exit costs, because the tooling comparison alone will not settle the decision.

Where the cloud bill surprises a team that just left a colo

The line that moves most after a colo exit is data transfer, not compute. In a colo the network is a fixed cross-connect and a committed bandwidth contract, so moving data between systems costs the same whether it is one terabyte or fifty. In a hyperscaler the equivalent movement is metered, and a workload profile built on chatty internal traffic can produce an egress bill that no colo invoice prepared the team for. Model the data flows before the move, not after the first month's bill.

The second surprise is utilisation. A colo estate is usually sized for peak and paid for continuously, so the average utilisation is low and the cost per useful unit of work is high. Cloud pricing rewards the opposite profile: spiky demand that can be turned off, or workloads that scale down when nobody is using them. A steady database running at high utilisation is the workload where the colo was genuinely cheaper, and it is the one to test for repatriation before the exit is signed.

Microsoft's page states that Azure Migrate can right-size workloads and use AI assistance to compare options and build a decision-ready story for stakeholders. That is the assessment step, and it is where the egress and utilisation numbers should be produced. A team that runs the assessment and then ignores its cost output is paying for the tooling and taking the risk anyway.

The shortlist a colo tenant actually compares

Three options are live for a team leaving a colo: move to AWS, move to Azure, or keep a smaller footprint and repatriate the steady workloads. The pages here support a comparison on migration tooling, published commitments and the treatment of legacy workloads, but not on price, because neither vendor publishes a migration price and the colo exit costs are site-specific.

AWS's differentiator on these pages is breadth of transformation: VMware, bare metal, mainframe, Windows, storage migration to Amazon FSx for NetApp ONTAP and Amazon EBS, and a model-to-model migration assessment that maps OpenAI, Gemini and Anthropic dependencies to Amazon Bedrock with an estimated cost saving. Microsoft's differentiator is the assessment-first path through Azure Migrate and the regional footprint, with the page claiming more than 60 announced regions and over 50 compliance certifications specific to global regions and countries.

The repatriation option has no vendor page here and no published price, which is itself the finding. A team considering it needs its own numbers for power, space and refresh on the reduced footprint, and it should ask both cloud vendors what the exit or data-transfer cost would be if the repatriated workloads later moved back. That question is rarely asked at signing and always asked at renewal.

What to ask before the colo notice goes in

Ask AWS and Microsoft for a scoped migration price covering discovery, assessment and execution on the named estate, in writing, with the assumptions listed. Ask what the assessment will produce on egress and utilisation, because those two numbers decide whether the cloud bill beats the colo invoice after year two. Ask for the data-transfer cost of the workloads that will move the most data between systems, priced at the volumes the assessment measured rather than at a sample.

Ask the colo provider for the exit terms: notice period, termination fee, cross-connect cancellation charges and the date the power contract ends. Those numbers belong on the before side of the comparison and they are the ones most often left out. Ask the hardware vendor what the refresh would cost if the estate stayed, because that figure is the strongest argument the cloud side has and it should be stated rather than assumed.

Finally, ask both cloud vendors which workloads their own assessment flags as poor fits. A vendor that will not name the workloads it does not want is giving a sales answer, and the repatriation case is built from exactly that list.

The decision rule for a colo exit this quarter

Choose AWS if the estate carries mainframe, Windows or VMware workloads that need transformation as well as relocation, because AWS Transform's published scope covers those and the model-to-model migration assessment addresses AI provider dependencies in the same workbench. Choose Azure if the priority is assessment before commitment and the estate has to stay inside named regions, because Azure Migrate's discovery and six R assessment plus the stated regional and compliance footprint support that path. Keep a reduced footprint and repatriate if the assessment shows steady, high-utilisation workloads whose egress and compute cost in cloud exceeds the colo's power, space and refresh over five years, and get that comparison in writing before the exit notice is served.

The number that decides it is the five-year total on both sides, and the number neither vendor publishes is the migration project price. A team that gets that quote, models egress at measured volumes and puts the refresh cycle inside the window will have a defensible answer. A team that compares the colo invoice to a cloud estimate will not.