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

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 goes down at once. A recent Hacker News thread described exactly that: a small company lost all of its production applications for nearly two weeks after its cloud account was suspended over a billing and credits dispute, while support gave conflicting answers. This post is the order I would 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 one 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, most providers support changing the account email, adding your company as a payer, or moving resources into an organisation you own.

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.

I work on software takeovers at Omni Care. If you want a fuller list of what to collect as proof during a handover, there is a takeover evidence checklist you can work through with your team.

Disclosure: this post was written by the Omni Care team with AI assistance, and the author works at Omni Care.

This guide was first published on 2026-10-24 on a blog that is no longer available; the text is unchanged apart from this note and the link tracking.