What you must own at the end of a project
At the end of a project you must be able to leave with the site without asking anyone’s permission. It is not a matter of trust: it is the only protection that holds when a supplier closes down, becomes unreachable or falls ill. Here is the list, and above all how to check it is true.
What must be in your name
- The domain name, registered to your company as registrant, with direct access to the registrar’s interface. A domain held by a supplier is the most frequent and most serious point of lock-in.
- The hosting account, at OVH or elsewhere, with your own credentials. If hosting is pooled by a supplier, insist at minimum on knowing where it is and being able to leave.
- Site administrator access, with an account in your name depending on no other. The back office is not a favour done to you, it is your working tool.
- Access to files and database: file transfer credentials, access to the database admin interface, and knowledge of the server all this lives on.
- The source code, including bespoke work done for you, with the right to have it modified by someone else. This is settled in the contract, not at delivery.
- Third-party accounts: payment provider, carriers, analytics, marketing tools. Each in your name, each with your credentials.
- Backups, or at minimum knowledge of where they are, how often they run and how to restore them without your supplier.
The domain, the only genuinely irreversible point
Everything else can be rebuilt. A lost site restores from a backup, hosting changes, development gets redone. A domain name held by someone else cannot be recovered by force: it is a contract between the registrar and its registrant, and you are not a party to it.
Checking is simple and takes two minutes: query your domain’s public registration data and read the registrant name. If it is not your company, it is not your domain, whoever pays the annual invoice. The administrative contact matters just as much: that is who authorises a transfer.
This check is worth doing today, even on a site that has run perfectly for years. The day the problem is discovered is almost always the day it has already become urgent.
How to check the list is real
-
Read the domain registrant, not the invoice
Payer and registrant are two different things. Only the registrant counts. Check the expiry date too, and the administrative contact address, which must be one you read.
-
Log in yourself, on a quiet day
Open every interface with your own credentials on an ordinary day: hosting, site admin, database, payment account. Access never used is access you do not know works.
-
Download a complete backup and keep it
Files and database, at your end, off the server. It is the only copy surviving both a host incident and a falling-out with a supplier.
-
Restore that backup once
On a separate environment, to prove it is usable. A backup never restored is not a backup, it is a file you have hopes about.
-
Write the account list and keep it current
Which service, which login, who else has access, and where the second authentication factor lives. That document is worth more than it looks the day the person who knew is gone.
Related pages
-
Domain names
Registration, transfer, DNS configuration and associated email addresses.
-
Backing up a shop before work
The complete method, files and database, with restore verification.
-
Domain no longer pointing anywhere
What happens when an expiry or a change goes unnoticed.
-
Passwords and shared access
How to organise access when several people work on the site.
Frequently asked questions
Does code built for me belong to me automatically?
Do I have to manage hosting myself to own it?
My supplier refuses to hand over access, what now?
Is a backup at the host enough?
What happens if my supplier closes down?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.