You bought a business — now take over its domain, email, and handles

Taking over an acquired business’s online identity is three separate jobs, and they get harder in a specific order. The domain is the most tractable: transferring one is at least a defined, regulated process with published rules. Email is harder: neither Google nor Microsoft offers a change-of-owner transaction for a Workspace or Microsoft 365 tenant, so what you inherit is admin control, not ownership. And the social handles are where the asset list can turn out to be unenforceable: several major platforms prohibit account transfers outright, meaning part of the “social media presence” you think you bought may be something the seller cannot legally hand over. The guide below works through all three, starting with whether anything legally has to move at all.

This article is general information, not legal advice — treat it as a list of questions to bring to your lawyer, not a substitute for one.

Does the deal structure decide what has to move?

Yes — it decides whether the domain legally has to move at all.

In a share (stock) purchase, you acquire the company itself. Assets the company owns — including a domain registered in the company’s name — stay exactly where they are, because their owner hasn’t changed; what changes is who controls that owner. No registrant change is required — though check whether any agreement covering the name carries a change-of-control clause, because a registrar agreement, a reseller contract, or a trademark or software licence can require consent or notice on a share sale even when the registrant field never moves.

In an asset purchase, you acquire specific assets, and only those. The domain must be affirmatively transferred to you — if it never moves, you never own it.

A share purchase only carries what the company actually owns, though: a domain registered to a founder personally isn’t a company asset and needs its own transfer regardless of structure — one reason to verify the registrant before closing.

Two cautions. This article won’t tell you which structure to choose — that decision involves far more than the domain. And even when no transfer is legally required, everything below still applies: ownership on paper doesn’t hand you the registrar password, the admin console, or the seller’s recovery phone number.

Deal structure is the most lawyer-shaped topic on this page — get advice on your actual transaction before relying on any general description.

How does the domain itself change hands?

Two mechanisms, and the right choice can save real time.

• A push moves the domain between two accounts at the same registrar. The current holder starts it, no authorization code is needed, there’s no ICANN-mandated waiting period, and it’s typically instant — the fastest clean handover, if you’ll open an account at the seller’s registrar.
• An inter-registrar transfer moves the domain to your registrar. The new registrant starts it, it requires an authorization code from the losing registrar, and it completes through the registry process — full walkthrough in how to transfer a domain to another registrar.

A word on the code itself, because much of what’s written about it is ahead of the actual rules. Under the Transfer Policy in force it is still the AuthInfo code. Where a registrar doesn’t provide facilities for the registrant to generate and manage their own, it must supply the code within five calendar days of the registrant’s request. You’ll see the name “Transfer Authorization Code” (TAC), along with a fixed expiry and one-time use, described as current — those are part of the pending reform covered below, not today’s policy. In practice many registrars already expire codes voluntarily, so don’t accept one the seller generated months ago; build the request into the closing timeline instead.

Separate from that is the ordinary registrar lock — the clientTransferProhibited status you’ll meet in the domain glossary. It’s the standard anti-hijacking lock, and it must come off before an inter-registrar transfer will run. Where there’s no self-service toggle for it, the registrar must remove the lock within five calendar days of the registrant’s request. Check the status before assuming.

Buying a domain on its own, without a business attached? How to buy a taken domain covers that narrower deal.

Will the 60-day lock catch you?

Quite possibly, so plan around it rather than discovering it. ICANN’s Change of Registrant process triggers on any material change to the registrant name, registrant organization, or registrant email address — exactly the fields an asset purchase changes. (Older write-ups add the administrative contact email; that trigger was dropped when the policy was updated to match the Registration Data Policy.) Both the prior and the new registrant must confirm the change, typically by email, before it takes effect. And since 1 December 2016, registrars have been required to impose a 60-day lock against inter-registrar transfers after such a change.

The practical consequence: update the registrant details first and the domain sits at the seller’s registrar for 60 days before it can move to yours. One sequencing follows from that rule — transfer first, then update the registrant details once the domain is at your registrar, so the 60-day stay applies somewhere you don’t mind it.

There is an opt-out, and how much it helps depends entirely on where the domain lives. The policy says registrars may offer one, only the prior registrant — the seller — can use it, and only before the change request is submitted. Some don’t offer it: DNSimple states plainly that it doesn’t. But the two largest retail registrars both do, and one does it by default — GoDaddy presents the 60-day lock as an explicit yes/no choice at the moment you update registrant contacts, while Namecheap’s registration agreement opts every customer out in advance and appoints Namecheap as Designated Agent, so neither party even receives a confirmation email. Ask the seller’s registrar early; don’t assume the lock is coming, and don’t assume it isn’t.

That also answers a question people often treat as unresolvable: the lock follows the registrant-data change, not the transfer mechanism. So a same-registrar push that also changes the registrant’s name, organization or email is a change of registrant, and can carry the lock — but whether it actually does is a registrar setting rather than an inevitability.

Two more locks exist that this section hasn’t mentioned, and they catch deals for unrelated reasons: a domain can’t be transferred for 60 days after initial registration, or for 60 days after a previous inter-registrar transfer. If the seller registered a defensive domain or consolidated registrars shortly before signing, that clock is already running.

The rules above are current as of publication, but substantial reform is coming and it reshapes this whole section. The ICANN Board adopted the Transfer Policy Review recommendations on 7 June 2026. They are not yet in effect — an Implementation Review Team still has to turn them into policy language, and there is no live effective date. What they do, though, is more than trim a waiting period: change of registrant is lifted out of the Transfer Policy into a standalone Change of Registrant Data (CORD) policy, and along the way the 60-day post-change lock, the Designated Agent role, and the requirement to obtain confirmation from both the prior and new registrant are all removed. The registration and post-transfer locks drop to 30 days. The rename of the AuthInfo code to a Transfer Authorization Code, with a time-to-live, arrives in the same package. Don’t schedule a closing around any of it yet — but if you’re reading a guide that describes the TAC or a 30-day lock as current, that’s why it’s wrong.

And if the domain isn’t a gTLD, almost none of the above applies. ICANN’s Transfer Policy binds accredited registrars and gTLD registries — .com, .net, .org, .io and the rest. Country-code registries write their own rules, and they differ at the mechanism level, not just the margins. A .co.uk moves by changing its IPS tag: no authorization code, no ICANN 60-day lock, and Nominet runs its own registrant-change process with its own fee. .de uses DENIC’s KK procedure with an AuthInfo of its own. If you’re buying a European business, the domain is quite likely a ccTLD, and the right first question is which registry’s rules govern it — not which of the above steps to follow.

Can you actually take over the email system?

Not the way you take over a domain. Neither Google nor Microsoft offers a vendor-blessed change-of-owner transaction for a tenant: in practice, “acquiring the email system” means taking over admin control of the existing tenant, or migrating mailboxes into a new one.

Google Workspace has no formal ownership transfer. Super Admin is a role, not a property of an account: an existing Super Admin grants Super Admin to your people, and the previous admin’s access must then be removed manually — nothing happens automatically. Billing is where the entity change bites: Google’s documentation states you cannot change the legal entity information on an existing invoiced billing or reseller account. The documented paths are transferring the subscription to a Google partner — who sets up a new billing account under the new entity without losing Gmail, Drive, or Vault data — or cancelling and re-creating, which genuinely risks data loss.

Microsoft 365 reaches the same destination by a different road, and the difference is worth money to you. Microsoft’s support article states plainly, “You cannot transfer an existing Microsoft 365 subscription from one Microsoft account to another,” and there is no formal tenant ownership transfer between distinct legal entities. The two real paths are the same as Google’s: transfer administrative control — grant Global Administrator to your admins and remove the seller’s, with the datacenter region staying unchanged — or run a full tenant-to-tenant migration of users, data, and licenses.

Where Microsoft differs is the paperwork underneath. Google says the legal entity on an invoiced billing account simply cannot change. Microsoft publishes a process for exactly that: an admin can edit the billing account name, the “doing business as” name, the sold-to address and the registration number in the admin center, and for the organization name itself Microsoft provides a legal-entity update form to submit with support and supporting documentation. Only the country or region is fixed. So if the deal leaves you choosing which side’s tenant survives, the Microsoft one can be re-papered into your entity’s name and the Google one can’t.

For the purchase agreement, spell out the admin handover explicitly — who grants which roles, and when the seller’s access is removed — because no platform process will do it for you.

Which social handles can the seller legally hand over?

The useful dividing line is not “personal versus business account.” It’s whether the platform models the thing as an asset with an assignable owner role — Facebook Pages, LinkedIn Company Pages, YouTube Brand Accounts, GitHub organizations and repositories, each with a supported transfer or owner-reassignment mechanism — or as an account licensed to one person — X, Instagram, TikTok, LinkedIn personal profiles, GitHub personal accounts — where handover breaks the terms and leaves the buyer no durable footing:

Platform	Transfer/sale allowed?	Supported mechanism
X/Twitter	No — terms prohibit “trading, buying, selling…or transferring accounts, usernames, or access”	None
Instagram	No — Terms of Use §4.2 bars attempts to buy, sell or transfer any aspect of an account, including the username	None for personal/creator accounts. A Professional account in a Meta Business Portfolio can have access reassigned by adding the buyer as Admin and removing the seller — that changes control, not ownership in Meta’s terms
Facebook Pages	Mechanically yes, contractually murky — Meta’s Spam standard prohibits selling, buying or exchanging Pages and admin roles, and its terms require Meta’s permission to transfer an account	Add the buyer as Admin/Full Control in Meta Business Suite; the Page can then be removed from the seller’s portfolio and added to the buyer’s. Routine in practice, rarely challenged, not an authorised sale
TikTok	No — terms updated July 2026 say plainly: do not “transfer your account to anyone else, without our permission.” TikTok may also reclaim or reassign a username	None for ownership. TikTok Business Center can reassign account and asset access to the buyer’s Business Center — control, not ownership
LinkedIn — personal	No — User Agreement §2.2 bars sharing or transferring an account	None
LinkedIn — Company Page	Yes, by role reassignment	A Super Admin assigns Super Admin to the new owner’s personal account. With no active admin, someone can add the company as their employer, verify with a company email address, and request admin access
YouTube (Brand Account)	Yes — the cleanest transfer of control of any platform here	Transfer “Primary owner” in Brand Account permissions. Both parties need 7+ days’ standing: the person making the change must have been an owner that long, and the recipient a manager or owner. Channels not on a Brand Account must be converted first. Note: monetization does not come with it — see below
GitHub — personal account	No — terms bar assigning or delegating rights without written consent	None
GitHub — repo / organization	Yes, official	Transfer a repository via Settings → Danger Zone (the new owner must accept within 1 day); organizations support multiple Owners, so control passes by adding the buyer as Owner and removing the seller

One caveat on the “cleanest” label above, because it’s the most expensive footnote in the table: a YouTube Brand Account transfers control, not revenue. AdSense accounts aren’t transferable — they stay bound to the seller’s Google account — so the new primary owner has to link their own and re-establish the channel’s YouTube Partner Program standing. Subscribers, watch time and views carry over. If you’re valuing an acquired channel on its ad income, price that gap in.

Sellers do sometimes just hand over credentials to a non-transferable account. Be clear-eyed about what that is: a terms violation that gives you no standing with the platform, no protection if the seller reclaims access, and an account that can be suspended at any time. Worth weighing when you read the asset list: an audience on a transferable surface and the same audience behind a licensed personal username are not the same thing. It’s checking the handle, not just the domain, in reverse.

What order should the security handover follow?

No ICANN document, registrar, or platform publishes an official handover sequence — what follows is convergent practitioner practice, not policy. It converges for a reason — step four:

1. Registrar account access, with fresh two-factor enrollment on your own devices.
2. Recovery email and phone moved off the seller.
3. DNS provider access, if DNS lives somewhere other than the registrar.
4. The domain’s own mailbox — the password-reset path back into the registrar, the DNS provider, and most of the rest. Whoever controls that mailbox can quietly undo steps one through three.
5. The seller’s payment method removed from auto-renew, replaced with yours.
6. API keys and webhooks rotated.

The underlying logic is the same as in how to stop your domain being stolen: control of the reset paths beats knowledge of the passwords.

What silently breaks after closing?

The worst failures have a delay on them:

• Auto-renew tied to the seller’s card. Once that card is cancelled, the renewal fails and the domain can lapse. Recovering an expired domain is a much worse read after the fact.
• DNS hosted in the seller’s own account, separate from the registrar. If that account closes, the zone can disappear — taking the site and the mail routing down together.
• Email authentication records. A registrar transfer by itself doesn’t break email — reconfiguring DNS or MX does. But SPF, DKIM, and DMARC records don’t move with a registrar transfer, and must be recreated at the new DNS provider or deliverability breaks. Setting up email on your domain covers each record.
• SSL/TLS renewal. Certificate renewal — especially ACME DNS-01 or HTTP-01 validation — can fail if DNS or hosting access changes mid-cycle. The site works on closing day and breaks when the certificate runs out.
• The expiry date itself. Domains can and do expire mid-deal because nobody checked.

What should you verify before you close?

Four checks, all cheap, all before signing:

• Which registry’s rules govern the domain. gTLD or ccTLD decides which of the mechanics above even apply, and it’s the cheapest check on this list.
• Who the registrant actually is, via WHOIS/RDAP — not who the seller says controls it. What you can see there is limited these days (GDPR, WHOIS privacy, and your domain covers why), so also have the seller demonstrate control from inside the registrar account.
• The exact expiry date, so the domain can’t lapse between signature and handover.
• The registrar lock status, so a planned transfer doesn’t stall on day one.
• Whether the domain sits in a reseller or agency account rather than the seller’s own direct registrar account. Reseller-held domains can’t be transferred by the seller alone, and access can vanish with the reseller relationship.

While you’re in the record, look at the name’s past too — a domain’s history comes along with the purchase, reputation and all.

What if you decide not to inherit the name at all?

Occasionally diligence makes the call for you: the handles that carry the audience are licensed to someone who can’t lawfully transfer them, or the name is entangled with the seller. When and how to rename a project covers switching without losing what the business built — and if you go looking for a new name, Domain Yoga returns around 250 availability-checked, brandability-ranked ideas per search, at $2–$5 a search. If you’re inheriting the identity, everything above was the relevant part.