Data-center exit is complete when required operations and recovery no longer depend on the departing facility. Application relocation is a component of that outcome. Shared identity, name resolution, networks, storage, monitoring, and backup can keep the facility necessary after application servers have moved.
The exit plan therefore needs an explicit final dependency boundary. Counting relocated workloads cannot establish that the remaining source infrastructure can be disconnected without losing a required capability.
Shared services can disappear from diagrams too early
A migration diagram may omit common services to make application groups readable. That presentation choice does not remove those services from the operating design or the facility’s closure criteria.
Suppose a relocated application still authenticates through an identity service at the old site and its backups remain accessible only through that network. Its normal screen can work through temporary connectivity while the facility remains essential to both access and recovery.
This constructed example illustrates the acceptance gap. The shared-service inventory needs owners, destinations, consumers, and evidence that each dependency has moved, been replaced, or received another explicit disposition.
Discovery traffic needs interpretation
AWS portfolio wave-planning guidance states that discovery traffic alone cannot establish every dependency or latency tolerance. Application-owner input and business or operational constraints remain necessary.
A quiet capture period can miss monthly processing or a recovery path used only during failure. Observed communication also does not by itself explain whether a call is essential, optional, or sensitive to increased latency.
Combine traces with configuration, operating procedures, business calendars, and representative workflows. Keep unresolved dependencies visible instead of treating absence from a traffic graph as evidence of independence.
Temporary connectivity has a completion condition
A bridge between source and destination can make staged migration feasible. It can also prolong source dependence if the plan never assigns an owner and removal condition to the connections it supports.
Each wave should describe the temporary state: which stores are authoritative, which interfaces cross sites, what latency is acceptable, and how recovery works. Later waves need the observations from those transitions.
A risk ranking cannot supply this sequence alone. Shared data, release windows, scarce staff, and business dates constrain what can move together and when.
The destination needs an operating model
Moving a virtual machine to a cloud provider changes infrastructure responsibility without automatically transferring every operating task. AWS’s EC2 responsibility model leaves guest operating-system updates, installed application software, and security-group configuration with the customer.
The destination plan should assign patching, backup, restore, incident response, access, monitoring, and cost management at the selected service boundaries. Another cloud service can divide those duties differently.
Technical, commercial, security, and workforce participation also matter to the change. Usage-based bills require assumptions and controls appropriate to the new design rather than an automatic expectation of savings.
Prove independence at the final boundary
A controlled disconnection rehearsal, or equivalent targeted dependency validation where a full rehearsal is impractical, should test critical work and recovery without the source facility. Its scope and any untested conditions need explicit recording.
Include name resolution, authentication, batch exchange, monitoring, restore, and access to required records. A successful normal request cannot demonstrate every failure-time dependency.
Facility contracts, physical removal, and applicable obligations require their own organization-specific evidence. Technical acceptance is the point at which required operation and recovery have a demonstrated path independent of the site, with remaining responsibilities assigned to the destination’s operating model.