Every cloud migration plan we review rehearses the same things: the data move, the cutover window, the DNS swing, the rollback. All of it matters. But ask who can get back into the cloud account in eighteen months if the person who set it up is gone and the payment card on file has expired, and the room usually goes quiet.
We run cloud migrations for mid-market estates, and the go-live checklist we bring includes a section most plans skip entirely: administrative continuity. It is boring on purpose. It is also the difference between an incident and an outage you cannot end.
The failure mode is circular
The pattern that takes companies down is never one mistake. It is several small ones wired into a loop, usually during the migration itself, when everything is being reconnected at once.
The recovery email for the cloud account lives on a domain that is hosted inside that same account. Billing alerts go to an inbox nobody monitors, or a spam filter eats them. Multi-factor authentication lives on exactly one device belonging to exactly one person. The payment card on file has an expiry date nobody tracks. Any one of these is trivial. Together they mean that when the account is suspended, every path back in is inside the thing you are locked out of.
What we check before go-live
Root recovery that does not depend on the account. The root and recovery email addresses live on a domain hosted somewhere other than the account they recover. If your DNS, your email, and your account access all move to the same provider in the migration, you have built the loop yourself.
Two people, two devices. Multi-factor authentication on hardware keys where the provider supports them, enrolled for at least two humans, with custody written down. One phone in one pocket is a single point of failure that no amount of architecture fixes.
Billing treated as an operational dependency. A backup payment method. Card expiry dates on a calendar someone owns. Invoicing instead of a card where the provider offers it. Billing is not the finance team's problem during a migration; it is uptime.
Alert routing you have actually tested. Send a test billing alert and a test security notification and confirm a human sees both. An alert that lands in a filtered folder does not exist.
A break-glass page. One document that says who calls the provider, what proof of ownership exists (account numbers, invoices, the legal entity on the agreement), and what support tier you are on. You write it now because you will not be able to look it up later.
Why this belongs in the migration plan
The migration is the one moment all of these dependencies are on the table anyway. Ownership is being established, DNS is moving, billing is being set up, and the people who understand the estate are paying attention. Bolting continuity on afterward almost never happens, because after go-live the account becomes background infrastructure until the day it is not.
We treat this section of the checklist with the same weight as the cutover rehearsal, for the same reason we treat application-level migration checks as non-negotiable: the failures are cheap to prevent and expensive to survive. If you are planning a move onto AWS or weighing which cloud fits the estate you actually have, this is part of what a real migration readiness review covers.