Every cloud migration plan we review rehearses the same things: the data move, the cutover window, the DNS change, the rollback. Then we ask who can get back into the cloud account eighteen months later, after the person who set it up has left and the card on file has expired. The room usually goes quiet.
The fix is administrative continuity: the ability of your organization, not one person, to sign in, pay, receive alerts, and prove ownership of the account on any given day. Build it during the migration, while every dependency is already on the table. We run cloud migrations for mid-market companies, and this section of our go-live checklist is the one most plans skip.
How do companies get locked out of their own cloud account?
Lockouts come from several small gaps wired into a loop, not from one mistake. The loop usually forms during the migration itself, when everything is being reconnected at once.
The recovery email for the account sits on a domain whose DNS is hosted inside that same account. Billing alerts go to an inbox nobody reads, or a spam filter eats them. Multi-factor authentication (MFA) lives on one phone that belongs to one person. The payment card on file has an expiry date nobody tracks. Each gap is small. Together they mean that when the provider suspends the account, every path back in runs through the thing you are locked out of.
What we check before go-live
Each check below breaks one link in that loop, and none of them needs new tooling.
Recovery that does not depend on the account. Host the root and recovery email addresses on a domain that lives somewhere other than the account they recover. If DNS, email, and account access all move to one provider, you built the loop yourself.
Two people, two devices. AWS lets the root user register up to eight MFA devices and recommends more than one. Enroll hardware security keys for at least two people. Write down who holds each key. One phone in one pocket is a single point of failure that no architecture fixes.
Billing treated as uptime. Add a backup payment method. Put card expiry dates on a calendar someone owns. Use invoicing instead of a card where the provider offers it. During a migration, billing is not a finance task. It is an availability dependency.
Contacts that outlive one employee. AWS supports separate billing, operations, and security alternate contacts, and its documentation calls a company email address, rather than one person's, the best practice. Point each contact at a monitored group address.
Alert routing you have tested. Send a test billing alert and a test security notification. Confirm a person sees both. An alert that lands in a filtered folder does not exist.
A break-glass page. Write one document that says who calls the provider, what proof of ownership you hold (account IDs, invoices, the legal entity on the agreement), and which support plan you are on. Write it now, because you will not be able to look it up later.
Why account access belongs in the migration plan
The migration is the only moment when ownership, DNS, billing, and the people who understand the systems are all in the same room. Continuity work bolted on after go-live almost never happens. Once the site is live, the account becomes background infrastructure until the day it is not.
We give this checklist section the same weight as the cutover rehearsal. The reason is the same one that makes the application checks in our CF2025 migration field checklist non-negotiable: these failures are cheap to prevent and expensive to survive. The work is also identical whichever provider you pick, a point we make in our AWS vs Azure comparison for Windows and ColdFusion apps.
If you are planning a move onto AWS, administrative continuity is part of what a real migration readiness review covers.