Closing a datacenter is a cost decision before it is a technical one. Ours was a colocation site, space we rented in someone else’s building, and it had changed hands several times over the years. Each new owner brought a new pricing structure, and the cost of staying there was climbing fast enough that keeping our hardware in that room had stopped making sense.
A lease we were leaving
It also ran against where the company was headed. The plan was to consolidate operations into our own facilities by 2028 and get out of the properties we only leased, both this colo and the corporate office building. The colo was the natural first move, because closing it meant relocating data and hardware, not people. That set the assignment: roughly sixty production services out of that building and into our consolidated environment, out before the contract date so the savings were real rather than planned, and gone without any of the plants that depended on them noticing.
That framing shaped everything that followed. A closure that slips its deadline keeps paying an escalating bill, and a migration that takes a plant down trades that bill for lost production, which is a far more expensive line. The only version of this that helped the business was the one that hit the date and stayed invisible.
Production set the schedule
The services in that building had grown organically for a decade. Some were customer-facing, some fed plant operations directly, and several were wired into vendor and EDI integrations with their own change-control calendars. The dependencies between them were not always written down, so cutting one in the wrong order could take out something three racks away. Every maintenance window also had to fit around live production: shift changes and planned line stops at multiple plants, customer EDI cutoffs, and vendor change freezes. Production set the schedule, and I worked inside it.
Running it as a program
So I ran the closure as a phased program rather than a single weekend cut. I inventoried every service and ranked it by how critical it was, how deep its dependencies ran, and which plants or partners depended on it, then built the migration order from that map instead of from the rack diagram. Each service got a fully built and tested landing zone waiting in the destination before anything moved. Where I could, I replicated the VM and its data ahead of time, so the actual window came down to a final delta sync, a DNS or routing change, and a validation check. Shared infrastructure and domain services went first, and the applications that leaned on them followed only once those were verified stable. Before every window I held a short go/no-go, and if a plant had a surprise production run or a partner froze changes, the cut moved. Nothing was worth a line going down.
What it released
The cutovers ended up boring, which was the goal. Every server moved with under fifteen minutes of downtime, and most landed inside five to ten. No plant took an unplanned hit, and every site kept running its scheduled work for the length of the program. The building emptied on time, the contract and circuits were released, and a colocation bill that had only been rising came off the books entirely. It also cleared the first and easier half of the consolidation, leaving the corporate office move as the remaining step toward the 2028 goal. Disaster recovery quietly improved along the way, since consolidating those services brought them under the same backup, monitoring, and security controls as the rest of production instead of sitting off on their own.
The boring part was the work. Every hour spent mapping dependencies, pre-staging landing zones, and talking to plant managers in advance was an hour not spent troubleshooting at two in the morning with a line stopped. It landed without drama because I treated the production schedule as the fixed constraint and shaped the IT work around it, rather than asking the business to shape its week around mine. A closure is only a win if the savings show up and nobody on the floor can tell it happened.