Planning a data centre exit

Leaving a colocation facility or shutting down a server room is a migration with a hard deadline attached to a contract. That changes how you plan it. The technical work is the same as any other migration; the difference is that the date is not negotiable and the penalty for missing it is financial and immediate.

Most exits go wrong in the same few places, and almost all of them are discovered late.

Before you give notice

Notice periods are usually long (six to twelve months is common) and they are usually the last chance to renegotiate anything. Do this work before the notice letter, not after.

Read the contract properly

Find the answers to these specifically:

• The notice period, and when it must be served relative to the renewal date. Missing the window by a week can commit you to another full term.
• What "vacated" means. Most contracts require the space returned to its original condition. That can include removing cabling, cabinets, containment and anything else you installed. Decommissioning labour is a real cost and it is routinely left out of exit budgets.
• Early termination terms, if the migration might finish ahead of the date.
• Whether cross-connects and cabling are billed separately and how they are cancelled. These often continue billing after the equipment is gone because nobody cancelled the circuit.

Find out what is actually in there

Nearly every exit discovers equipment nobody could account for. Do not rely on the asset register alone. Walk the floor, photograph every rack, and record what is powered, what is cabled and what is neither.

For each device, you need to know what it does, who depends on it, and who authorised it. Expect a handful where nobody knows. Those need a decision, and "leave it running somewhere else" is the most expensive one.

Map the circuits

Network circuits terminating in the facility are frequently the long pole. New connectivity can take months to provision, and the lead time is outside your control. Identify every circuit, its contract term, its notice period, and what replaces it. Start the replacement procurement before you start the migration.

Building the plan backwards

Work from the exit date, not forwards from today.

1. Exit date. The day the space must be empty and clean.
2. Decommissioning window. Physical removal, cabling, disposal, and the facility's own sign-off. Allow more than you think; facilities have access rules and slot availability.
3. Buffer. Two to four weeks of nothing planned. This is what absorbs the workload that turns out to be harder than expected, and there is always one.
4. Last workload moved. Everything must be migrated and stable by this point.
5. Migration window. The bulk of the work.
6. First workload moved. Early enough that the process is proven before volume starts.
7. Today.

If that arithmetic does not fit, you have found out now rather than in month nine.

The order to move things in

Group by dependency, not by ease. Applications that share a database or talk to each other constantly should move together. Splitting them means running traffic between the old facility and the new environment for the duration, which is slow, adds cost, and creates a dependency on the very circuits you are trying to cancel.

Move something real early, a workload with genuine users but survivable downtime, to prove the process end to end. Keep the truly critical systems for the middle of the window, when the process is proven but there is still buffer left.

What gets forgotten

Physical dependencies. Licence dongles, hardware security modules, fax lines, out-of-band management, anything with a serial cable. These do not migrate and each one needs a specific decision.

DNS and certificates. Long time-to-live values on DNS records extend cutover windows. Lower them well ahead of the move. Certificates tied to hostnames that change need reissuing.

Backups of things you are switching off. You will need to retain data from decommissioned systems for longer than the systems themselves exist. Decide where that lives and how it is restored, before the source is gone.

Data destruction. Drives leaving the facility need to be wiped or destroyed to a standard you can evidence. If you are regulated, you will need certificates of destruction. Arrange this in advance; it is not something to organise in the final week.

The monitoring. Monitoring systems often live in the facility being vacated, which means visibility disappears exactly when you need it most. Move monitoring early.

Running two environments at once

For most of the project you will be paying for both. This is unavoidable and should be in the budget from the start rather than appearing as an overrun.

Reduce the overlap where you can by decommissioning in stages. As racks empty, consolidate and hand back space if the contract allows partial returns. Check whether it does before assuming.

The last month

Two things matter in the final stretch.

Confirm nothing is still talking to the old environment. Not by asking, by measuring. Leave the network path in place but log every connection, and chase each source. There is almost always one forgotten integration, and finding it after the circuit is cancelled is much worse than finding it before.

Get the facility's sign-off in writing. Billing does not stop because the racks are empty. It stops when the provider agrees the space is returned. Book that inspection early and confirm what they will check.

A note on timing

Exits that fail usually fail because notice was served on an optimistic plan. The contract date then drives the technical decisions rather than the other way round, and quality drops as the deadline approaches.

If the honest estimate does not fit the notice period, the options are to negotiate an extension, accept a short-term overlap at a higher rate, or reduce scope by retiring more workloads. All three are better than compressing the migration, and all three need to be raised early enough to be possible.