A migration plan can account for every server, screw, shipping case, and maintenance minute yet remain unsafe to execute. The missing items are usually not objects. They are relationships: which business service needs which database, which circuit must be accepted before which wave, who can approve rollback, and whether the old environment can still carry production after the point at which the plan assumes it can.
The physical move matters. But the go/hold decision should be made from the state of the dependency system, not from the readiness of the truck or rack.
An inventory tells you what exists; a dependency map tells you what can move
An asset inventory answers useful questions: what equipment exists, where it is, who owns it, and perhaps which service tag or serial number identifies it. It does not establish which assets must change state together.
A database server may depend on an application tier that is staying temporarily at the source. A router may be installed at the destination while its carrier circuit remains unaccepted. An appliance may have a valid configuration backup while the license, firmware compatibility, or management credential needed after replacement is unavailable. A business owner may approve downtime without understanding that the rollback environment will be dismantled before functional acceptance is complete.
This is why high-confidence dependency information is central to migration planning. AWS Prescriptive Guidance explicitly includes both communication data and nontechnical operational dependencies, and notes that they determine which applications must move together and which can operate from different locations. Its wave-planning guidance also recognizes that no single data source reveals every dependency.
That last point is operationally important. Network telemetry can show communication, but not whether a transaction can tolerate latency. A CMDB can show a relationship, but not whether the named owner is still available. A rack elevation can show placement, but not whether facility access is approved for the people named in the MOP. A sound plan reconciles machine-discovered evidence, configuration records, operator knowledge, contracts, and direct destination checks.
The Migration Dependency Map connects fourteen readiness layers
Treat the Migration Dependency Map as a controlled register whose evidence state is refreshed before each wave, rather than a diagram frozen at project kickoff.
Every dependency receives one of five states: verified, verified with condition, unverified, blocked, or not applicable with rationale. “Ordered,” “expected,” and “the provider confirmed” are notes, not readiness states, unless the plan defines the evidence that makes them sufficient.
Use the map when forming waves and at the final go/hold review. Required inputs are the service map, asset inventory, destination design, circuit and access records, vendor plan, approved execution procedure, rollback conditions, and acceptance criteria. The migration manager maintains the register, but only the named technical or business owner may accept a condition in that owner’s domain.
The framework’s limitation is deliberate: it coordinates specialist evidence; it does not replace carrier acceptance, customs advice, transport insurance, security approval, or engineering sign-off where those are required.
Destination readiness must be demonstrated before source risk is created
“Installed at destination” is not a useful gate unless the word installed has an evidence package behind it. A practical destination-ready record should cover at least:
- correct rack, device, and port identity;
- expected power and cabling state;
- accepted carrier handoff and production-path test;
- reachable management plane from the authorized operating environment;
- current configuration, firmware, license, and compatibility evidence where relevant;
- confirmed access for the execution window and contingency period;
- available tooling and a prepared replacement path;
- monitoring ownership and acceptance-test method.
Operational preparation of a replacement component illustrates the difference. A RAID controller, iDRAC or iLO module, or network interface card may be physically compatible while the recoverable state still depends on exported configuration, appropriate firmware, licensing, UEFI settings, target-system compatibility, and an approved validation path. The same principle applies to the destination as a whole: presence is an input; recoverable production capability is the result of preparation and evidence.
Material uncertainty may remain, provided it is visible to the person authorizing the wave. A low-impact monitoring refinement might be accepted as a post-migration condition. An unaccepted production circuit is usually a different class of decision.
The wave readiness record produces a go or hold decision
Use one record per migration wave. The blank structure requires evidence behind every green status.
The record should be reviewed at least twice: early enough to remediate blockers and again close enough to execution that volatile evidence—access, carrier state, logistics, and source availability—remains valid.
Worked hypothetical: the rack is ready, but the wave is not
Hypothetical migration case. The quantities and time windows below are illustrative only. A company plans to relocate two application servers and one edge device into a new colocation rack. The plan treats the wave as executable because the rack, A/B power, hardware, and destination patching have been inspected.
Three facts change the decision:
- The primary carrier circuit is delivered but has no customer acceptance record.
- The management interfaces respond locally, but access from the authorized remote operations path has not been tested.
- The commercial termination plan requires the source rack to be released 12 hours after the move, while the rollback plan assumes it can remain active for 48 hours.
The wave record therefore shows Destination Ready: verified with condition, Circuit Ready: blocked, Rollback Available: blocked, and Go / Hold: hold. The decision does not depend on optimism about migration night. The circuit owner must produce an end-to-end acceptance test; the operations owner must validate management access from the real control path; and the migration manager must align source retention with the rollback window.
Without the dependency map, these items appear in three separate workstreams and may meet only during the incident. With it, the project discovers the contradiction before equipment leaves the source.
Rollback is a temporary operating state, not a paragraph in the MOP
A rollback plan remains real only while the source data, service, connectivity, people, authority, and time needed to execute it remain available. Each irreversible step narrows that option. Data divergence, route changes, contract cessation, equipment removal, or credential revocation can create a point after which “roll back” means a new recovery project.
Microsoft’s migration-planning guidance recommends tested rollback procedures, defined timeframes and success criteria, formal rollback authority, and explicit go/no-go checkpoints. NIST’s contingency-planning guidance similarly separates recovery from reconstitution and requires validation before normal operation is declared.
For example, copying a database back is not a rollback if the old network route cannot be restored inside the remaining window. The wave plan must identify the last safe rollback point, the evidence that triggers it, the person authorized to decide, the maximum decision time, and the validation that proves the source has resumed the required service.
The map should not duplicate knowledge that has no decision effect. Its purpose is to expose contradictions between workstreams, convert assumptions into named evidence, and stop a wave only when an unresolved dependency can defeat execution or recovery.
A concise pre-migration decision check
Before authorizing a wave, confirm:
- the service-to-asset map is current and signed off by the service owner;
- hard dependencies are inside the wave or have a tested split-state design;
- destination rack, power, cabling, circuits, and management access have acceptance evidence;
- access approvals cover the planned window and credible overrun;
- vendor, logistics, customs, and transport tasks have named owners where applicable;
- the approved MOP matches the final asset and port plan;
- prepared spares, tools, configurations, and licenses cover defined failure cases;
- monitoring and alert ownership transfer at a specified step;
- rollback remains physically and logically possible until a named point;
- go, conditional-go, hold, and rollback authorities are present;
- acceptance tests measure the business service, not only device reachability;
- unresolved conditions have owners, deadlines, and an explicit effect on the decision.
Program consequence. A hold becomes a controlled risk decision with a closure owner, rather than an unexplained schedule slip discovered during the migration window.
The resulting consulting output is a migration-readiness assessment containing the dependency register, wave gates, access and vendor matrix, rollback criteria, and acceptance checklist. Management receives a defensible answer to one question: which wave can proceed under which conditions, and who is accepting what remains uncertain?
Authorize the wave from evidence, not momentum
A migration wave is ready when its required dependencies are evidenced, its conditions are owned, rollback remains valid for the promised interval, and a named authority can accept the resulting service. The model cannot guarantee a fault-free move, but it prevents the project from converting known contradictions into migration-night surprises.
For a migration into or within Azerbaijan, I can combine dependency-led planning and local readiness validation with controlled on-site evidence gathering. The deliverable is a wave-level go/hold record that remote engineers, local providers, and business owners can use in the same decision window.