You paid for the site, so it is yours. That is how it looks, and usually nobody is lying.
Except a "site" is not one object. It is seven separate things, each with its own account and its own procedure. And the question people usually land on — "whose name is it in?" — is the wrong one. Most of these are perfectly practical to leave with whoever builds and runs the site, and more often than not that is the better arrangement.
The useful question is different: can it move to you, by what procedure, and at what cost?
That is a shorter list and a far more concrete conversation.
Two arrangements, both fine
In practice there are two kinds of client, and neither is wrong.
Some want everything centralised with the developer. The domain, the hosting, the accounts — all held by the firm that runs the site, paid for out of their budget, with the client settling it in one invoice alongside maintenance. The advantage is real: no chasing six renewals across three cards, and nothing falls over because a card expired in February and nobody opened the warning email.
There is exactly one condition, and it gets confirmed in writing at the start: on departure you receive everything, so that you depend on them for nothing.
Others want to own it all from day one and hold each account directly. That is an equally valid choice. It costs a little more administrative attention, and that is the whole difference.
What actually matters is that the firm you work with is flexible about both. A firm that can only work one way — either "we hold everything, there is no other option" or "we do not touch your accounts, sort it out yourself" — is imposing its operating model instead of the one that suits you.
The list below works identically either way. What changes is who presses the buttons day to day, not what you must be able to obtain.
The seven
1. The domain
In practice, the most convenient arrangement is for the firm building the site to hold the domain. They configure the DNS, they catch the renewal, they talk to the registrar when something needs changing. Domains that expire are almost always domains nobody was watching in particular.
What makes that arrangement safe is not holding the keys yourself. It is that transferring a domain to another holder is a routine operation, done on request to the registrar, and it is done every time.
How it works, in general
There are two distinct operations, and they get confused often:
- Change of holder — the domain stays with the same registrar, the name in the registry changes.
- Transfer between registrars — the holder stays the same, the company the domain sits with changes.
You may need one, the other, or both.
The mechanism in either case is an authorisation code (also called a transfer code, auth code or EPP code). The current holder requests it from their account with the registrar and hands it over. The receiving side submits it, and both email addresses on file confirm. That is the whole thing.
- For .md, the registry is nic.md, run by the Information Technology and Cyber Security Service. The authorisation code is requested directly from the user account on nic.md, and the transfer to another holder is done online.
- For .com, .net, .org and the other international domains: unlock the domain first, then the same authorisation code. It takes days, not weeks.
One thing to plan around: after certain changes, registrars refuse a new transfer for a period — commonly 60 days. Not a problem, just a reason not to change both supplier and registrar in the same week.
What to settle in advance
Two sentences, in writing: that the transfer happens on request, and what it costs. The right cost is the registrar's fee plus a little of someone's time. Nothing beyond that.
The one thing here that genuinely matters
The domain should be registered to the company, not to the personal name of someone inside it. A company can sign a transfer request four years later. An employee who has since left and stopped answering the phone cannot.
2. The hosting
Same logic. A server held by the firm that runs the site is a normal arrangement and usually a better one than the alternative: a single machine they know, patch, monitor, and hold backups for that they have actually tested.
And migrating to your own server, if the day comes, is routine work: the code, the database, the files, one DNS record. A day, most of it waiting for propagation.
So the question is not "is it on my server". The question is what runs there, and can it be reproduced elsewhere. If the answer is "a standard runtime and a standard database", you are free whenever you like. If it is "a platform of ours that installs nowhere else", you bought something different — possibly something good, but the contract and the price should say so plainly.
One exception that matters: applications built to order. A bespoke CRM, an internal ERP, software written specifically for your company genuinely does depend on a particular server and a particular environment — it is tied to integrations, to background services, to a database and a configuration designed alongside the application. That is not commercial lock-in, it is the nature of the product.
There the question changes. Not "why does it not run anywhere", but whether the environment is documented and can be stood up again: what runs, at which versions, with which variables, and at what effort. A good answer describes the effort, in days and steps. "It runs nowhere else" is not a technical answer.
Still ask whose account it sits on and who pays, so you do not find out on an inconvenient day.
3. The code
Yours at the end. Not necessarily along the way, and the reason is legitimate.
A branch in progress carries temporary passwords written straight into the code for testing, keys pointing at test accounts, half-migrated data. That is how you validate things quickly. Handing that over mid-build is not transparency; it is a security problem and a source of questions nobody has time to answer.
The code runs on the server — that is where it lives. What has to exist in addition is a copy in a version control system — Git, in practice — hosted on an external platform: GitHub, GitLab, Bitbucket, or a self-hosted instance such as GitLab or Gitea.
The difference is not a formality. Version control keeps the history of every change, allows a return to an earlier state in minutes, and makes the project independent of any single machine. Without it, "the code" means the current contents of a directory on a server: no history, no way back, and nothing to hand on except an archive.
So what gets agreed is this: the project is kept on such a platform from the start, and at handover you receive access to it, complete and cleared of the temporary values.
How to check: ask which version control platform the code is kept on, and since when. It is a technical question with a short, checkable answer.
4. The payment accounts
The contract with the bank or payment provider should be in your company's name, with the money landing in your account. This part is usually fine, because the bank demands the company documents anyway.
What gets missed more often is access to the merchant dashboard — the one where you see transactions and issue refunds. It sometimes stays with the developer alone, without anyone having decided that.
5. The measurement accounts
Analytics, Search Console, the business profile, the ads account.
These get created quickly, often on the email of whoever is doing the work, and they stay there. Access is easy to grant; what does not come back is the history, if an account has to be recreated from scratch. Two years of data does not return.
How to check: open each one and look at who the owner is, not who has access.
6. The content
The text, the photographs, the illustrations.
If the photographs were bought from a library, the licence is in someone's name and it has terms. Worth knowing whose and which, especially if you want the same images on a brochure or a billboard.
7. How it starts
The document that says how it is installed, which environment variables it needs, how a new version is published. The cheapest thing to write at the right moment and the most expensive to reconstruct two years later.
The warning signs
Not "we hold the domain" — that is the normal situation. Five other things, though, are worth a conversation:
- "It cannot be transferred", or an answer that cannot say how it is done. It is a routine registrar procedure. The signal is not that they hold the domain, it is that nobody can describe the next step.
- A transfer priced as a penalty. Migration is a few hours of work plus the registrar's fee. A figure that looks like a ransom describes the relationship, not the work.
- The domain in a person's name rather than the company's. The one real risk in this whole article.
- Code that only runs on their infrastructure — on an ordinary site or shop. That is genuine dependency, and it is a different thing entirely from the server currently being theirs. The exception is the one in point 2: an application built to order legitimately depends on its environment, and what you ask for there is the environment's documentation, not portability.
- Only one possible arrangement. If you cannot choose between "you hold everything" and "I want the accounts in my company's name", the choice was made for you.
What a complete handover looks like
One message, seven points, each with a link or a proof:
- Domain — registrant is your company, or a confirmed transfer on request with the procedure written down
- Hosting — account, panel, who pays, what runs there
- Code — access to the version control platform, temporary values removed
- Payments — contract in your company's name, merchant dashboard access
- Measurement — your company as owner on every account
- Content — what was bought and under which licence
- Startup — the installation document
The list is useful before signing too, alongside the rest of what is worth asking when you choose who builds it.
The answer to the question in the title is duller than it sounds. The site is yours from the moment each of the seven can move to you on request — not from the moment you are the one holding the keys. Whoever builds and runs it usually has good reasons to hold them. What there is never a good reason for is being unable to explain how they get handed on.