Who owns what after launch: a plain-language handover checklist
A surprising number of organisations discover they don't actually control their own website only when they need to change something urgently — a new developer, a hosting migration, a compliance requirement — and find that the domain, the hosting account, or the source code isn't accessible to anyone currently on staff. This is entirely avoidable, and it costs nothing to prevent at the time of launch.
The four things that actually need to be owned
Domain registration. The domain should be registered in the organisation's name, at a registrar the organisation has its own login to — not in a developer's personal account, 'for convenience,' with a promise to transfer it later. Later rarely happens on schedule.
Hosting and infrastructure accounts. Whoever pays the hosting bill should be able to log into the account that bill pays for. If a developer's personal cloud account is quietly running your production site, you don't have a hosting relationship — you have a dependency on that one person staying reachable and cooperative indefinitely.
Source code. The organisation should have its own copy of the complete, buildable source code, not just access to a live server. A git repository under an account the organisation controls, with a working build process documented, is the minimum bar.
Content and data. Whatever content management system or database sits behind the site, someone on the organisation's side should know how to export the data — articles, records, customer information — independent of the platform staying online.
Why this gets skipped
It's rarely deliberate. Most of the time it happens because setting things up under a developer's existing accounts is faster during the build, and the plan to transfer ownership after launch gets deprioritised the moment the site is live and everyone's attention moves elsewhere.
The fix isn't more paperwork at the end — it's inverting the order. Set up accounts under the organisation's ownership before the build starts, and grant the development team access into them, rather than the other way around.
A handover checklist worth actually using
Before calling a project finished, confirm: the domain is registered to the organisation with the organisation holding registrar access; hosting is billed to and controlled by the organisation; a complete source code repository exists under an organisation-owned account with documented build steps; content export is tested and confirmed to work; and there is a named, current point of contact for support — not a generic inbox that may or may not be monitored a year from now.
None of this is about distrust of whoever built the site. It's about the ordinary fact that people change roles, agencies close, and priorities shift. Ownership set up correctly at launch means none of that becomes an emergency later.
Takeaways
- Domain, hosting, source code and data export are the four things that must be owned by the organisation, not merely accessible.
- Set up accounts under organisational ownership before the build starts — transferring them afterward is where handovers go wrong.
- A working, tested content export matters more than a promise that data 'can be exported' if needed.
- A named support contact beats a shared inbox nobody is accountable for reading.