The Data Centre Exit: What Actually Forces the Decision

Nobody closes a data centre because cloud is fashionable. They close it because several things come due at once and renewing them all stops making sense.

Having sat in a few of these conversations, the trigger is almost always one of six things. Usually more than one.

The six triggers

Hardware reaching end of support is the most common. Not end of life, end of support. The moment a vendor will not sell you another year of maintenance, your risk position changes and somebody senior has to sign off on carrying it.

Storage pressure runs a close second. You are out of capacity, the expansion quote is worse than it should be, and the array is already past replacement. Spending real money to extend something that should have gone already is a hard case to argue.

Facilities catch up with everyone eventually. Cooling specified for a smaller load. A generator at the end of its life, or a landlord who will not replace it. Power that was fine when the room was half empty. These are building problems, and technology teams have no levers on them at all.

A licensing or virtualisation renewal does it too (cough Broadcom). A large number lands, it is worse than last time, and suddenly there is an appetite for a genuine comparison rather than a rubber stamp.

A major programme already underway is the best trigger of the lot. Replacing a core business system means touching everything around it anyway, so doing the platform work at the same time costs less than doing it twice. If you have one of these running, it is the strongest argument you will ever get.

Then there is the people cost, which rarely gets counted and is often the largest. Every hour spent on firmware, capacity planning, cooling alarms and failed drives is an hour not spent on something the business actually asked for.

It never works out quite the way people expect, though, because cloud is still hard to manage. The firmware and the failed drives go away. Identity, patching, cost control and monitoring do not, and they need different skills. Count the hours you get back honestly, or the business case promises a saving the team never sees.

What never shows up in the comparison

Most cloud versus on-premises comparisons are built on compute and storage. Then reality adds the rest.

Egress charges, if you move a lot of data out. Backup and disaster recovery, priced separately. Licensing, which often changes when you move and not always downwards. The skills gap, because your team now needs different capabilities. And the overlap period, where you pay for both because nothing migrates cleanly on the first attempt.

Build those into the number up front. A business case that skips them gets reopened in month four, which is much worse than a higher honest number at the start.

Not everything should go

Be clear about this early, because it changes the shape of the programme.

Workloads with genuine latency requirements to something physical. Systems where the vendor does not support a cloud deployment, or supports it badly. Anything with a data sovereignty constraint you cannot satisfy. Applications so old that re-platforming costs more than the remaining life of the application.

Plan for a hybrid end state and treat full exit as the ambition rather than the requirement. The programmes that get into trouble are the ones that committed to closing the room before working out what could not leave it.

Sequencing that works

Inventory first. Every workload, what it depends on, who owns it, what it costs to run now. This is unglamorous and everything downstream depends on it.

It is also the step we built Arcio for, and it is what we use on these programmes. Every server and application sits in one model with an owner, a run cost and a decision against it, and before anything is switched off it shows what else stops working.

Build the target landing zone properly before anything moves. Retrofitting that later is a much bigger job, which we covered in Azure Landing Zones.

Move the easy things first. Development, test, file services, anything without a complicated dependency. Each success proves the pattern and builds the confidence you will need for the hard ones.

Then take the hard workloads deliberately, one at a time, with a rollback plan for each.

Decommission as you go. This is the step everybody defers and it is where the savings live. A data centre with three servers left in it costs nearly what a full one costs, because the power, cooling, floor space and support contracts do not scale down.

Put a date on the room

Set a date to close the facility and work backwards from it.

Without one, the last 10 percent never moves. There is always a reason to leave something where it is for another quarter, and the business keeps paying for a building that houses almost nothing.

The date will move. That is fine. A date that slips six months still shaped the schedule, and it is the only thing that generates the pressure to finish.

Element Digital does infrastructure work in Hobart and across Tasmania. If you are weighing up an exit, get in touch.