Naming Your Owners: Who Decides What Moves in a Data Center Migration
Most data center migrations do not fail because of a single technical mistake. They stall because nobody clearly owned the decisions. A server gets left behind because no one knew whether it belonged to accounting or operations. A cutover waits three hours because the person who could approve it was unreachable. Before anyone unplugs a rack, a small business should answer a simpler question than most checklists ask: who is allowed to decide what, and who must be reached when a decision is needed fast? This article walks through how to assign those roles and what to ask so the answers hold up when the move is underway.
Separate Business Owners From Technical Owners
Every system in a server room has two kinds of owner. The business owner is the person who depends on the system's output and can say whether it is still needed, what downtime is acceptable, and what a broken result would cost the team. The technical owner is the person who knows how it is configured, patched, backed up, and connected to other systems. In small businesses these roles often collapse into one person, or they are held by people who have never discussed them. Before the migration, build a simple register listing each system, its business owner, its technical owner, and the name of a backup for each. Blank entries are findings. A blank business owner means nobody can approve retirement or downtime for that system, and that system will generate delays on migration day.
Ask the business owner directly whether the system is still in use. Old file servers, forgotten print servers, and legacy line-of-business applications frequently continue running long after their purpose ended. Deciding to retire them before the move is cheaper than migrating them and discovering later that nobody used them.
Define Decision Rights for the Move Itself
A migration produces decisions that cannot wait for a committee: whether to proceed when a pre-move check fails, whether to extend a cutover window, whether to roll back a system that appears to be misbehaving. Write down who holds each of these decisions. A useful pattern is to name one accountable decision-maker for the business, one for technical go or no-go calls, and one person authorized to approve spending or scope changes if something unplanned comes up. Record the contact method for each, including what to do if the person is unavailable.
Be specific about thresholds. Instead of writing that a problem should be escalated, write the condition that triggers escalation, such as a restore test that does not complete, a dependent application that cannot reach its database, or a cutover running past the planned window. Specific triggers remove the hesitation that usually costs the most time during a live move.
Questions to Ask Before Migration Day
The following questions are worth answering in writing before the move. Who can authorize a rollback, and do they have the access to perform or request it? Which systems have a hard deadline, such as payroll runs, end-of-month reporting, or customer-facing order processing? Who needs to be told when a system goes offline, and in what order? Which vendors or outside technicians need access during the window, and who approves their entry? What is the agreed definition of a completed move for each system, and who signs that it meets the definition?
For each answer, note where the information lives. If a decision depends on a document that only one person has, that is a single point of failure. Store copies of the register, the escalation list, and the sign-off criteria somewhere the whole team can reach even if the server room is offline.
A Practical Ownership Checklist
Before scheduling the cutover, confirm the following. Every system in the inventory has a named business owner and technical owner, with a named backup for each. Every system has been marked as keep, migrate, or retire, and the business owner has approved that status in writing. The decision-makers for go or no-go, rollback, and scope changes are named, with contact methods and an unavailability plan. Escalation triggers are written as specific conditions rather than general instructions. Completion criteria exist for each system, and the person who signs off on completion is identified. Outside parties needing access are listed with the internal person who approves each entry.
When every line on this list is filled in, the migration has a chain of accountability that works under pressure. When lines are blank, the blank lines become the agenda for your next planning meeting. Settling ownership in advance will not eliminate every problem on migration day, but it ensures that when a problem appears, someone already knows whose call it is and how to make it quickly.