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 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.
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.
“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:
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.
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 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.
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.
Before authorizing a wave, confirm:
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?
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.