Cloud Planning
Part of Cloud operations governance
Planning a cloud handover when an external provider leaves
Transfer cloud operations from an external provider with a service inventory, usable runbooks, checked procedures and controlled access removal.
Plan a provider handover as a transfer of operating ability, decisions and access. The incoming team should be able to identify each workload, follow its essential procedures and reach the right contacts before the outgoing provider's access ends. Set a dated acceptance point and keep gaps visible.
Establish what the provider operates
Start with the agreement and a current inventory of accounts, subscriptions or projects, workloads, shared services and environments. Record who controls billing, tenant administration, identity, DNS, monitoring, backups, deployment systems and support cases.
Include subcontractors and tools supplied through the provider. Reconcile the contract's description with current configuration and operating records.
Name an internal handover owner and an incoming operator for each service. Transfer open incidents, planned changes, exceptions and relevant renewal dates. Assign interim cover before the outgoing team departs if a task still lacks a receiving owner.
Transfer usable knowledge
Collect current architecture and resource records, runbooks, alert routes, backup and recovery instructions, deployment procedures and known failure modes. Record where the documents live, who can use and update them, and which versions are current.
AWS operational guidance says runbooks should include required permissions, error handling and escalation and be updated as procedures change.
Arrange for the incoming operator to carry out a representative routine task and an incident or recovery walkthrough under suitable safeguards. Record what was actually checked and what remains open. Console access alone does not establish that the team can resolve an alert or restore an application.
| Handover item | Acceptance question |
|---|---|
| Account and billing control | Can an authorised internal owner manage the account and receive notices? |
| Monitoring and support | Do alerts and cases reach the new operator? |
| Procedures and deployment | Can the new operator follow the current version with approved access? |
| Recovery | Are the recovery owner, copies, instructions and latest exercise result known? |
| Open work | Does each incident, exception and change have a receiving owner? |
Change access in a controlled order
Inventory the provider's human accounts, groups, delegated roles, service accounts, keys and integrations. Arrange the incoming operator's access, then remove outgoing access through each mechanism in use and check the resulting grants. Plan the sequence around any service identities or automation the provider operates.
The removal method depends on the arrangement. An authorised customer or provider user can remove an Azure Lighthouse delegation. Microsoft warns that removing one of several delegations can also disrupt another when they share the same principal and role.
Google Cloud's documentation for a Marketplace service-account feature says cancelling a purchase does not itself revoke the provider service account's project access; the customer must remove that access and address resources created for it. An AWS cross-account role can grant another account access to selected resources, so inspect relevant roles when that method was used.
Rotate or retire provider-held credentials through the change or incident process where needed. Check that the intended workloads still run after access changes. An access-removal confirmation alone does not close the handover.
Close the service and data position
Confirm the contract's export window, formats, assistance and treatment of remaining copies. If personal information is involved, the privacy owner should assess the applicable arrangement.
OAIC guidance includes reasonable steps to destroy or de-identify personal information entities hold once it is no longer needed, unless an exception applies. The guide is not legally binding, and the entity's obligations depend on its circumstances.
The handover record should name the accepted inventory, receiving owners, procedures checked, access changes, outstanding gaps and final decision. Give an essential unverified task an interim operator and deadline. Sign-off should describe the capability actually transferred.
