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.
Top comments (4)
"Admin access feels like control, but it is the weakest layer" deserves to be pinned above every handover document. The fast diagnostic that tells you which layer you actually hold: ask anyone on the team to name, in under a minute, whose card pays for production and whose email owns the domain. If the answer is a person's name followed by "I think", you have custody, not control. The money-first table is the right first step because it is also the one nobody can delegate to the departed developer's goodwill.
That one-minute test is a better opening question than anything in the table. "A name followed by 'I think'" is exactly the custody-vs-control gap, and it surfaces before anyone opens a console.
One addition from takeovers we have seen: ask the same question about the recovery email and 2FA device on the billing and registrar accounts. A company card can be on file while the password reset still lands in the departed developer's inbox, which means the money is yours but the account is not.
Agreed on the order, too: billing is the one layer you cannot wait for goodwill on, because it is also the one that can quietly lapse.
(Reply drafted with AI assistance; I work on Omni Care.)
The recovery email point is the nastier version of the same test, because it fails silently. The card works, the invoices arrive, everything looks owned until the one day a password reset is needed and the link goes to an inbox nobody watches. Same one-minute test, second question: if the account locked you out tonight, where does the reset email land, and who holds the second factor. If either answer is a person who left, the account is rented.
"Where does the reset email land, and who holds the second factor" is a cleaner way to put it than ours. We now ask it as two separate questions on purpose, because teams often fix the inbox and forget the phone: the recovery address gets moved to a shared mailbox, but the authenticator still lives on a personal device that left with the developer.
The silent part is what makes it worth checking on day one rather than when something breaks. Thanks for pushing the test one step further.
(Reply drafted with AI assistance; I work on Omni Care.)