Admin access, but no control of the cloud bill: the takeover order when billing and root sit with someone else

Short answer: if your team can use the app but someone else owns the cloud account, the domain registrar or the root user, work in this order: list every paying account and who controls it, secure the domain, export the data and prove you can restore it, request ownership or payer transfer with paperwork ready, and only then rotate keys and judge the code.

A common takeover situation looks fine on the surface. The original developer or agency is gone, but your team can still log into the app's admin panel, edit content and see users. What nobody has is the cloud account that pays for the servers, the registrar login for the domain, or the root user that can create and delete everything. Those sit under a former employee's email, a freelancer's credit card or an agency's company account.

Admin access feels like control, but it is the weakest layer. If the card on file expires, a billing dispute goes unresolved or the account owner simply stops responding, the provider can suspend the account, and every app on it can go down at once. Below is the order to work in before that happens, with a check for each step and what to do when a step fails.

Step 1: List every account that costs money, and whose card or email pays for it

Start with money, not code. Make one table with a row for each paying service: cloud hosting, domain registrar, DNS provider, email sending service, app store developer accounts, monitoring, and any SaaS the app depends on. For each row, write the login email, the payment method, the renewal date and who can actually sign in today.

Check: every row has a named person inside your company who has signed in this week. Rows where the answer is "the old developer" or "not sure" are your real risk list. Invoices in your accounting system and card statements are the fastest way to find accounts nobody remembers.

Step 2: Secure the domain before anything else

The domain is the asset you cannot rebuild. Servers can be recreated and code can be redeployed, but if the domain lapses or stays locked in someone else's registrar account, your email and website go with it. Look up the expiry date with a public WHOIS or RDAP lookup and compare it with today.

Check: the domain renews more than 60 days from now, auto-renew is on, and the registrar account email is a company address you control. If any of these fail, this is the first transfer request you send.

Step 3: Export everything the admin panel can export, and prove you can restore it

Use the access you have while you still have it. Export the database or content, user lists, uploaded files and configuration from the admin panel. Then restore that export somewhere you control, even a cheap test server or a local machine, and open it.

Check: the restored copy shows recent records, for example orders or sign-ups from the last few days. An export file that has never been opened is not a backup; it is a hope.

Step 4: Request ownership or payer transfer, with paperwork ready

Now ask for the transfer of the cloud account, the registrar account and any other row from Step 1 that is not yours. Prepare the contract or statement of work showing your company paid for the system, and the invoices that show who paid the hosting. If the previous owner is cooperative, many providers support changing the account email, adding your company as a payer, or moving resources into an organisation you own; check the current process with each provider.

Check: a person from your company is listed as owner or administrator on each account, billing uses a company payment method, and multi-factor authentication is tied to a company device or shared vault, not a former employee's phone.

Step 5: Only then rotate keys and plan code changes

It is tempting to start by rotating passwords and deploy keys, or by reading the codebase. Doing that before Steps 1 to 4 can lock you out of something you could not yet recover. Once you own the accounts and have a restorable copy, rotate API keys, deploy keys and admin passwords, remove old users, and only then start judging whether the code itself is in good shape.

When a step fails

• The cloud account is suspended for non-payment. Open a support case from the account owner's login if anyone can reach it, and attach invoices and the contract. In parallel, restore your Step 3 export on infrastructure you control so the business can keep running while the case drags on. Do not wait for support to answer before you start the restore.
• The provider or agency refuses to transfer ownership. Some providers will only act on the account holder's request, and some agencies treat hosting as leverage. Stop negotiating over the account and migrate instead: use the verified export, stand up a new environment you own, test it, and switch DNS once the domain is yours.
• Registrar privacy hides who owns the domain. Privacy protection is normal, but it means WHOIS will not tell you the owner. Use the registrar's own dispute or ownership-verification process and bring the invoices and card statements that show your company paid for the domain.

What "done" looks like

You are out of the danger zone when three things are true: every paying account has an owner inside your company, the domain is renewed and in your registrar account, and you have restored a recent copy of the data on infrastructure you control. Everything else, including whether to keep or rebuild the code, can be decided calmly after that.

For a fuller list of what to collect as proof during a handover, work through the takeover evidence checklist with your team. If the system is AI- or vibe-coded, the eight risks to check before touching the code are the natural next read.

About this article

This guide was first published on 2026-10-24 on an Omni Care blog that is no longer available, and republished on DEV on 2026-10-25. This is the Omni Care copy. Compared with the earlier text, a reference to a single Hacker News post about a suspended cloud account was removed because it is a self-reported account that we could not independently verify, and a short answer was added at the top.

Written by the Omni Care team with AI assistance; the author works at Omni Care. This is a takeover-order guide, not legal advice, a security audit or a guarantee that any provider will transfer an account. Provider processes change, so confirm the current steps with each provider.