More than half (54%) of the operators who answered the Uptime Institute’s 2024 survey said their most recent significant outage cost them more than $100,000, and roughly one in five said the bill went past $1 million. Those figures come from the Uptime Institute’s Annual Outage Analysis 2025, and they are worth keeping in mind before anyone starts pulling cables out of a rack.
A data center decommissioning project is one of the easier ways to cause that kind of outage by accident. If you shut down the wrong server, or you unplug a switch that an old payroll system still quietly depends on, the business feels it right away. The good news is that very few of these outages are bad luck. In most cases they come from a plan that skipped a step, or from a plan that existed on paper but was not followed on the day.
This guide lays out a phased decommissioning plan, roughly in the order a careful team would work through it, with a rough timeline for each phase so you can see how far ahead the work really needs to start.
What a Data Center Decommissioning Plan Actually Covers
A data center decommissioning plan is the written, step-by-step schedule for retiring IT equipment (or a whole facility) while moving the workloads that run on it somewhere else, and while making sure no data leaves the building on a drive it should not be on.
“Without disruption” has a specific meaning here. It does not mean nothing changes. It means users and customers (as well as any partner systems connected to you) keep working through every phase, and that each cutover is planned in a window the business has agreed to in advance.
Two terms come up a lot, so it helps to define them early:
- IT asset disposition (ITAD): the process of deciding what happens to each piece of retired hardware (reuse, redeployment, recycling, or destruction) and then documenting that outcome.
- Chain of custody: the signed record of who had a device, where it was, and when, from the moment it leaves the rack to the moment it is wiped, shredded, or recycled.
The Phased Plan at a Glance
Most decommissioning projects that run smoothly move through the same six phases. The timeline below assumes a mid-sized facility or a large equipment refresh; a single cage in a colocation site can compress it, and a full building shutdown will usually stretch it.
- Discovery and inventory (about 6 to 9 months before shutdown)
- Dependency mapping and cutover sequencing (about 5 to 6 months out)
- Migration in waves (about 2 to 5 months out)
- Disposition planning for every asset (runs alongside phase 3)
- Physical removal (the final 2 to 6 weeks)
- Close-out and sign-off (the 30 days after the last rack is empty)
Each phase has its own exit test. You should not move to the next phase until the current one passes it.
Phase 1: Discovery and Inventory
Everything else in the data center decommissioning process depends on this list, so it is worth doing slowly. The goal is a single inventory that records every physical device, every virtual machine, and every application, along with the owner of each one.
A useful inventory row includes:
- The make, model, and serial number of the device
- The rack and slot location
- Whether the device stores data (hard drives, SSDs, tape) or does not (most network gear, GPUs, and memory, which do not hold user data once powered off)
- The business owner, as well as the IT owner
- Any lease, warranty, or maintenance contract tied to it
The exit test for phase 1 is simple: the number of devices on the list matches the number of devices on the floor. If you walk the racks and find three servers nobody can explain, you are not done yet. In our experience those “ghost” servers are where surprise outages tend to come from, because someone, somewhere, is still using them.
Phase 2: Dependency Mapping and the Cutover Sequence
If you only have time to do one phase really well, it should be this one. Dependency mapping means working out which applications talk to which, which databases they read from, and which network paths, DNS records, and licenses they need in order to run.
Some teams use automated discovery tools that watch network traffic for a few weeks. Others interview application owners one by one. The honest answer is that you usually need both, because traffic monitoring will miss the job that only runs at quarter end, and interviews will miss the connection nobody remembers setting up.
Once the map exists, you group workloads into move groups (applications that must move together) and put those groups in order. Low-risk, well-understood systems go first; the systems the business cannot live without for even an hour go later, after the team has practiced the process a few times. The exit test is a signed cutover calendar with a named owner and a rollback plan for every move group.
Phase 3: Migration in Waves, With a Way Back
Migration is where most of the actual downtime risk in a decommissioning project sits. The safest approach is to move one wave at a time and to keep the old environment running, powered and untouched, until the new environment has been proven under real load.
A few practices make a large difference:
- Run the old and new systems in parallel for a set period (often one to two weeks for business-critical systems) and compare results.
- Schedule cutovers inside agreed change windows, and freeze unrelated changes during them.
- Take and test full backups before each wave, not after.
- Write the rollback trigger down in advance, for example, “if order processing errors pass a set threshold in the first two hours, we switch back.”
The Uptime Institute’s research also notes that staff failing to follow procedures has become a growing cause of outages. That matters here, because a migration runbook only protects you if people actually use it on the night. Keep the runbook short enough that it gets read.
Phase 4: Disposition Planning for Every Asset
This is the phase that tends to get rushed, and it is also where a data center decommissioning project carries the most risk once the migration is finished. The workloads have moved, so it is easy to think the job is basically done. It is not. Every drive that leaves the building still holds whatever was written to it, and the business is still responsible for that data.
The best practice is to assign each asset an outcome before it is unplugged, rather than deciding on the loading dock. In practice, that means four buckets:
- Reuse or redeploy: newer servers, switches, and memory that can be moved to another site or put back into service.
- Resell: equipment with remaining useful life, which can offset part of the project cost once any storage inside it has been wiped.
- Recycle: older gear with no further use, sent to a certified recycler so that nothing ends up in landfill.
- Destroy: any data-bearing device that cannot be wiped and verified, or that holds data sensitive enough that physical destruction is required.
The method has to match the media, which is where a lot of plans go wrong. Degaussing (exposing media to a strong magnetic field) works on magnetic media such as hard disk drives and LTO tape, but it does not work on SSDs or other flash storage. SSDs need a manufacturer secure-erase command, a cryptographic erase, or physical shredding.
GPUs, CPUs, and memory modules do not keep user data after power is removed, so they generally do not need destruction at all, and sending them to a shredder throws away equipment that could have been reused.
One of the providers that has built its data center decommissioning services around this per-asset approach is Big Data Supply, an R2v3 and RIOS certified ITAD company that starts each decommissioning project from the equipment list, assigns every item an outcome (resale, redeployment, recycling, or certified destruction) during disposition planning, and then backs each data-bearing device with a serial-level certificate of destruction and chain-of-custody records that follow the hardware from the loading dock to its final destination.
For teams running a data center decommissioning on a tight schedule, having the disposition decided before pickup means the removal crew is not making data security calls on the floor.
Whoever you work with, the exit test for phase 4 is a disposition list that matches the phase 1 inventory line for line, with a method named for every data-bearing device.
Phase 5: Physical Removal in the Right Order
When the last workload has moved and the parallel run has finished, the physical side of the data center decommissioning can start. The order matters more than people expect.
For an equipment refresh inside a building that will stay open, removal is mostly about not disturbing the racks that are still live. Label decommissioned racks clearly, power them down one at a time, and keep shared power and cooling untouched until you are sure nothing on those circuits is still in use.
For a full facility shutdown, the usual order is servers and core IT equipment first, then the supporting infrastructure. Power distribution, generators, and cooling (including HVAC) should be the last things to go, because the remaining equipment still needs to be powered and kept cool while it is being wiped and inventoried.
Every device should be scanned against the inventory as it leaves the rack, and data-bearing devices should go into locked, tracked containers right away. If the destruction happens off-site, the chain-of-custody record should show the handover with a signature and a time.
Phase 6: Close-Out, Documents, and Sign-Off
A decommissioning project is not finished when the floor is empty. A proper close-out usually covers:
- Collecting a certificate of destruction for every data-bearing device, matched by serial number to the inventory
- Collecting recycling documentation for everything that was not reused
- Cancelling maintenance contracts, software licenses, circuits, and leases tied to the retired equipment (this is often where the real savings show up)
- Updating the CMDB, DNS, firewall rules, and monitoring so old systems do not keep generating alerts
- A short review meeting with the business owners to confirm nothing was missed
If your organization handles consumer report information, the FTC’s Disposal Rule guidance describes doing due diligence on any disposal contractor you hire, including reviewing independent audits and checking references. Keeping those records in the close-out file saves a lot of searching later if an auditor asks.
Where Low-Disruption Plans Usually Break Down
Most of the problems that come up in a data center decommissioning trace back to a short list of causes:
- The inventory was built from old spreadsheets rather than a physical walk of the floor.
- Dependency mapping relied on interviews alone, so a quarterly or annual job was missed.
- The old environment was switched off before the new one had run under real load.
- Disposition was decided at the loading dock, so drives were mixed in with non-data equipment.
None of these are really technical problems; they are scheduling and discipline problems, and the fix for almost all of them is starting earlier than feels necessary.
Frequently Asked Questions
How long does a data center decommissioning take?
For a mid-sized facility, six to nine months from the start of discovery to final sign-off is a reasonable planning range. A single colocation cage or a small refresh can be done in a few weeks, while a multi-site shutdown can take more than a year, mostly because of migration testing.
What are the phases of data center decommissioning?
Most plans follow six phases: discovery and inventory, dependency mapping, migration in waves, disposition planning, physical removal, and close-out. Some teams combine the planning phases, but skipping any of them tends to show up later as downtime or missing paperwork.
Can you decommission a data center without any downtime?
You can usually avoid unplanned downtime, and for many systems you can avoid noticeable downtime altogether by running old and new environments in parallel. A few legacy systems may still need a short, scheduled maintenance window, which is fine as long as it is agreed with the business in advance.
What is the difference between data center decommissioning and ITAD?
Data center decommissioning is the whole project of retiring equipment or a facility, including migration and physical removal. ITAD is the part of that project that decides what happens to each retired device and documents it, from reuse and recycling through to certified data destruction.
Should we hire a certified recycler for the hardware?
For business equipment, yes. The EPA recommends certified electronics recyclers to businesses and other large purchasers, and notes that the two accredited standards (R2 and e-Stewards) require independent audits and the destruction of data on used electronics.
Key Takeaways
- Start discovery six to nine months ahead, and do not move on until the inventory matches what is physically on the floor.
- In our view, dependency mapping is the phase that prevents the most avoidable outages, so give it real time and use both tools and interviews.
- Migrate in waves, keep the old environment running until the new one is proven, and write the rollback trigger down in advance.
- Assign every asset an outcome before it is unplugged, and match the sanitization method to the media type (degaussing does not work on SSDs).
- Leave power and cooling until last in a full shutdown.
- Close out with serial-matched certificates, cancelled contracts, and a short review, because the paperwork is what proves the job was done properly.
