How do you calculate the cost of migrating from colocation to AWS?

Build two numbers that cover the same scope over the same period, usually three years. The colocation side is not just the monthly invoice: it includes rack, power, cross-connects, bandwidth commit, hardware refresh amortised across the term, support contracts, and the staff hours spent on hardware. The AWS side is compute and storage at a realistic utilisation rather than list price, plus data transfer out, plus the managed services that replace work people currently do by hand. The gap between the two is the run-rate change. The migration project itself is a separate one-time number and should never be blended into the run rate, because doing so hides whether the steady state is actually cheaper.

What is the most commonly missed cost in a colocation exit?

Data transfer out, usually called egress. Colocation bandwidth is typically bought as a flat commit, so nobody has a reason to measure how much data leaves the building. Cloud providers bill egress by the gigabyte, which means a platform serving large payloads to customers acquires a line item that did not previously exist. Estimate it from real traffic before the business case is signed rather than discovering it on the third invoice.

Should you lift and shift or re-architect when leaving colocation?

Lift and shift gets you out of the data center fastest and delivers the least financial benefit, because it puts the same workload on rented hardware, often at a higher run rate than owning it. Re-architecting toward managed services captures the real savings and takes considerably longer. Most engagements land on a split: lift what is stable and cheap to run, re-architect what is expensive. The important discipline is deciding which workloads are in which category before the budget is approved, not during the migration.

When does a colocation exit not save money?

Three situations, and all three are visible before you start. When the colocation contract has significant committed term left, paying it out can consume the first year of savings. When the workload is steady, predictable, and already well utilised, owned hardware in a colocation facility is frequently cheaper than rented capacity. And when the plan is lift and shift with no re-architecture, the run rate often goes up rather than down. A cost model that cannot show a saving in these cases is working correctly.

How long should a colocation to cloud migration take?

The technical work is rarely what sets the schedule. The contract renewal date, the split between lifted and re-architected workloads, and the length of the hybrid overlap period matter more. The overlap is where budgets slip most often, because it means running two sets of infrastructure, two sets of monitoring, and a network link between them. Treat that overlap as a defined phase with an end date rather than an outcome.

Colocation to AWS: How to Model the Real Cost

Most colocation exit business cases compare the colocation invoice to an AWS pricing calculator, decide the second number is smaller, and start moving workloads. Then the run rate goes up.

The comparison is not wrong because the arithmetic is wrong. It is wrong because the two numbers describe different things. One is a bill. The other is an estimate of a subset of a bill.

Here is what belongs on each side, and where the case usually breaks.

The colocation side is bigger than the invoice

The monthly colocation invoice is the most visible number and the least complete one. A model that uses it as the entire left-hand side will understate what you are currently spending, which sounds like it favours the migration but actually makes the whole comparison unusable.

What belongs on that side:

Rack, power, and cooling, which is the invoice itself.
Cross-connects and bandwidth commit, often billed separately and often forgotten.
Hardware refresh, amortised across the term. Servers bought three years ago are a cost being consumed now, whether or not cash moved this month.
Support and licensing tied to owned hardware, including hypervisor and backup licensing that may not follow you to a managed service.
Staff hours spent on hardware. Someone drives to the facility. Someone handles a failed disk. That time is real and it disappears after a migration, which is a genuine saving that most models omit because it never appeared as an invoice.

Leave any of these out and the migration looks worse than it is. Include them honestly and the case is at least being argued on real ground.

The AWS side is bigger than the calculator

The pricing calculator gives you compute and storage at list price, which is the floor rather than the number. Three additions usually decide whether the case holds.

Utilisation, not specification. Sizing cloud instances to match the specification of existing physical servers reproduces hardware that was deliberately over-provisioned for a refresh cycle. Size to observed utilisation and the number falls; size to the old spec sheet and you have bought the same excess capacity at a rental price.

Data transfer out. This is the cost nobody models, and it is the single most common reason a business case that looked sound stops being sound. Colocation bandwidth is bought as a flat commit, so nobody has ever needed to know how much data actually leaves. Cloud egress is billed by the gigabyte. A platform serving large payloads to its customers can find this becomes a meaningful line, and it should be estimated from real traffic before anything is signed.

Managed services that replace labour. Moving a database to a managed service costs more per hour than running it yourself on an instance, and less in total once the patching, backup verification, and failover testing stop being someone’s job. This belongs in the model as a saving on the labour side, not just a cost on the service side.

The migration is a one-time number and must stay separate

The project cost, professional services, dual running, tooling, and the internal time spent, is a real number and it is not part of the run rate. Blending it into a monthly comparison produces a figure that answers no question anyone asked.

Keep them apart and the model answers two questions cleanly. Is the steady state cheaper, and how long does it take to pay back the one-time cost? A business case that cannot separate those two is usually hiding the fact that the steady state is not actually cheaper.

Where the case usually breaks

Three situations, and every one of them is visible before a workload moves.

The contract still has term left. Colocation is bought on multi-year commitments with notice periods. Leaving significant committed rack and power on the table can consume the first year of savings entirely. The honest first question in any colocation exit is when the contract renews and what notice it requires, before anything about target architecture.

The workload is steady and well utilised. Cloud economics reward variable and bursty demand. A predictable workload on hardware you already own, in a facility you already pay for, is frequently the cheaper option, and a model that says so is doing its job rather than failing.

The plan is lift and shift. Moving virtual machines unchanged is the fastest route out of the building and delivers the least benefit: the same workload on rented hardware, usually at a higher run rate than owning it. The savings live in re-architecture, which takes longer. Most credible plans split the estate, lifting what is stable and re-architecting what is expensive to run.

The overlap is where budgets actually slip

Almost every migration runs both environments for a period. That period is the most reliably underestimated line in the model: two sets of infrastructure, two sets of monitoring, and a network link between them, all at once.

Plan the overlap as a defined phase with an end date. Treated as an outcome rather than a phase, it becomes a permanent hybrid estate that nobody chose and the business case never included.

What a usable model looks like

Two columns, three years, same scope on both sides. Run rate separated from one-time cost. Egress estimated from measured traffic rather than assumed. Utilisation taken from monitoring rather than from spec sheets. A named end date for the hybrid overlap.

If the model produces a saving under those conditions, the case is real. If it only produces a saving when the colocation side is reduced to the monthly invoice, the case is an artifact of the comparison rather than a property of the migration.

We published a case study on a SaaS platform’s move from colocation to AWS that walks through how these factors played out in a real engagement.

What It Actually Costs to Leave Colocation for AWS