Handing a website to a new owner, selling a business, transferring a client's site, passing a project to someone else, involves three separate things that people treat as one: the domain, the hosting, and the accounts everything else depends on.
Each moves differently, and the one that causes disputes is the domain.
The domain is the one that matters
Whoever is listed as the registrant legally holds it. Not whoever pays for it, and not whoever built the site.
Transfer it properly rather than sharing a login: the new owner creates their own registrar account, you unlock the domain and provide the authorisation code, and they initiate the transfer.
That takes days and cannot be rushed, so start it first, and note the sixty-day lock afterwards, during which it cannot be transferred again. How to Get Your EPP Authorization Code for Domain Transfer walks through the steps.
An alternative for the same registrar is an account-to-account push, which is faster. Either way the registrant details must end up as the new owner's, not merely the login.
Do not just hand over passwords
Sharing a login leaves you with access to something you no longer own, and leaves them depending on an account in your name.
Where the account can be transferred. A registrar push, a hosting account ownership change, do that. Where it cannot, the new owner creates their own and the content moves into it.
Either way, every password changes at handover. Not because anyone is suspected, but because "who still has access" must have a clear answer afterwards. How to Secure Your Hosting Account walks through the access review.
Inventory before you agree a date
Write down everything the site depends on. This list is the actual handover.
The domain and where it is registered. The hosting account. Mailboxes and forwarders. DNS records, including any pointing at third-party services. Payment gateway accounts. Analytics and search console. Every third-party subscription, plugins, themes, mail sending, monitoring, with its renewal date.
Anything not on the list stops working eventually, and it stops after the handover when nobody remembers it existed.
Third-party accounts often cannot move
The part that surprises people.
A premium plugin licence is usually tied to your account and may not be transferable: the new owner may need to buy their own. Payment gateway accounts are tied to a legal entity and cannot simply change hands. Analytics history can be shared by adding a user, but moving ownership of the property is a different operation.
Check each one before promising it. "The licence transfers" is a common assumption and a frequent disappointment.
Move mail deliberately
Mailboxes hold correspondence that may not belong to the new owner, and may be needed by the old one.
Decide per address: transferred, exported and deleted, or forwarded for a period. Then do it before DNS changes, because mail follows MX records and a change mid-handover lands messages somewhere nobody is watching. How to Migrate Email to a New Host goes into the sequence.
Personal data in those mailboxes may carry obligations of its own, which is another reason to decide rather than to hand over everything by default.
Take a complete backup at the moment of transfer
Both parties benefit from one.
The new owner gets a known starting point. The previous owner gets a record of what was handed over, which settles any later question about what was or was not included.
Verify it opens rather than assuming; an archive that will not extract is not a handover. What to Do Before You Cancel or Move Hosting explains what a backup does not contain.
Write down what is not obvious
Which plugins are load-bearing and why. Any custom code and where it lives. Scheduled tasks and what they do. Anything held together by a workaround.
A page of notes saves the new owner a week of reverse-engineering, and it is the difference between a handover and an abandonment. It also protects you from being asked questions for the next six months.
Agree an end to your involvement
A defined window. Two weeks, a month, during which you answer questions, and a date after which you do not.
Without one, informal support continues indefinitely and resentfully. With one, both sides know where they stand and the new owner knows to ask everything before it closes.
Then actually remove your access
After the window, remove yourself: from the hosting account, from the site's user list, from analytics, from the registrar account.
Holding access to a site you no longer own is a liability instead of a courtesy. If something goes wrong afterwards, being able to say plainly that you have no access is worth more than being able to help.
Check the FTP accounts and API tokens too, those are where forgotten access accumulates, and neither party thinks to look. What to Do When a Client Leaves deals with the same cleanup from a provider's side.
From the receiving end, with no handover at all, four questions come before touching anything. There is more in What to Do When You Inherit a Website Nobody Documented.
Transfer the accounts, not just the files
Handing a website to somebody else involves several accounts that are easy to overlook. The hosting, the domain registration, the certificate if it was purchased, any analytics property, and every third party service the site connects to each have their own owner. Transferring the files and leaving the registration in your name means the new owner does not control the domain, which is the thing that matters most. Make the list before agreeing a date, since each transfer has its own process and some take days.