A migration workbook is the single authoritative record of an infrastructure migration: what exists, what it depends on, where it is going, when, who is responsible, and whether it worked. Without one, that interdependent detail spreads across several documents that gradually stop agreeing, and teams end up planning against different data.
The migration workbook is the artifact that holds it. Whether it is a spreadsheet, a database, or a purpose-built tool matters far less than whether there is exactly one of it and everyone is working from it.
What Should a Migration Workbook Contain?
Eight sections: inventory, application mapping, dependencies, move groups, destination design, task detail, validation criteria, and a risks and decisions log.
The asset inventory is the foundation, as it is in the CIS asset inventory control: every device, with serial number, model, current location down to rack and U position, owner, and function. Everything else references this, which means an inaccurate inventory produces errors in every other section.
Application and service mapping ties assets to what they actually deliver — which applications run on which infrastructure, who owns each, and what business function depends on it. Assets without this mapping cannot be prioritized or sequenced sensibly.
Dependencies record what connects to what, in enough detail to build move groups. This is the section that most often exists only in someone's memory and most often causes the outage that nobody predicted.
Move groups and waves define what travels together and in what order, derived from the dependency map rather than from convenience.
Destination design records where each asset lands: target rack, U position, power circuit, network ports. This section is what turns arrival day into installation rather than improvisation.
Task detail breaks each wave into steps with owners, durations, and predecessors, at whatever granularity the team will actually maintain.
Validation criteria state, per system, what must be true for it to be considered successfully migrated — and who signs that off.
Risks, issues, and decisions capture what is unresolved, what has gone wrong, and what was decided. The decision log is the section teams most often omit and most often need, because the question of why something was done a particular way arises constantly and memory is unreliable.
How Do You Keep the Workbook the Only Source of Truth?
Enforce it structurally, because the workbook's value collapses the moment a second version exists.
This is not a hypothetical failure. It happens through ordinary behavior: someone exports a sheet to work offline, someone else keeps a personal copy of the rack layout, a vendor maintains their own inventory, and three weeks later two teams are planning against different data.
Prevent it structurally. Keep the workbook in one place with defined write access, make clear that copies are read-only snapshots, and give it a visible version and date so a stale printout is recognizable as stale.
Assign ownership. One person is responsible for the workbook's integrity — not for producing all its content, but for ensuring changes land in it and conflicts get resolved. Without that role, the workbook decays into a document that was accurate at kickoff.
How Detailed Should a Migration Workbook Be?
Only as detailed as the team will actually maintain. The opposite failure is a workbook so elaborate that maintaining it becomes the project.
Detail that nobody updates is worse than absent detail, because it looks authoritative while being wrong. A field that was populated once during discovery and never revisited will be trusted by someone six months later.
Collect what will be used and maintained. If nobody can articulate a decision that a given column informs, it does not belong there. It is better to have twelve fields that are current than forty where half are stale.
Match granularity to what the team can sustain. Task-level detail for a thousand assets is unmaintainable for most teams. Group-level detail with asset-level inventory underneath is usually the right resolution.
Make It the Working Document
A workbook consulted only at planning meetings is documentation. A workbook used during execution is a tool.
The practical test is whether the team works from it on move day. If the technicians on the floor are using printed sheets from the workbook and marking completion back into it, it is functioning. If they are working from a separate checklist someone made because the workbook was too unwieldy, it has failed and the separate checklist is now the real plan.
Design the execution views for the people using them. A technician needs their rack's install list, not the full program view. A project manager needs status roll-up. Same underlying data, different presentations.
What Happens to the Workbook After the Migration?
It becomes the as-built record, and it does not stop being valuable when the migration completes.
The final state — what ended up where, on which circuits, with which addresses — is the as-built record of the new environment, the kind of component inventory NIST SP 800-53 expects an organization to keep current. Handed to operations, it is the documentation the facility starts its life with, which is better than what most facilities have.
The decision log and the issues list are what make the next migration go faster. Organizations that consolidate or relocate once tend to do it again, and the second project starting from the first project's record is a materially different exercise from starting over.
Archive it deliberately, in a location operations will actually find, rather than leaving it in the project team's shared drive to be lost in the next reorganization.