Most business owners only think about website ownership when something goes wrong: the developer stops answering, the agency raises prices or the hosting account turns out to be in someone else's name. At that point, every missing password and unclear contract clause becomes a problem. A planned website ownership handover avoids all of this, whether you are switching providers, bringing work in-house or simply want to be sure you are in control.
This guide explains what you should own, how to set it up from day one and what a clean handover looks like.
The parts of a website you need to own
A website is not one thing. It is a set of assets and accounts, each of which can be controlled by different people.
| Asset | What it is | Who should control it |
|---|---|---|
| Domain name | Your web address, registered with a registrar | Your company, as registrant |
| DNS | Records pointing the domain to hosting and email | Your account, with delegated access |
| Hosting | The server or service running the site | Your account, or a clear contract if managed |
| Code | The application and theme files | Repository you own or have full access to |
| Database | Content, users, orders, settings | Regular backups you can access |
| Media files | Images, documents, downloads | Included in backups |
| Business mailboxes and sending | Your account, documented settings | |
| Third-party services | Payment gateways, maps, analytics, email tools | Accounts in your company's name |
| Licences | Paid plugins, fonts, themes, engines | Purchased in your name or clearly transferable |
If any of these sit entirely in a provider's personal account, you have a dependency, not ownership.
Setting up ownership from day one
The easiest time to get this right is at the start of a project.
- Register domains in your company's name using a role email address such as it@ or admin@ rather than an individual's personal email.
- Create hosting, repository and service accounts under your company, then invite your provider as a user.
- Use a password manager shared across your team so access does not depend on one person.
- Enable two-factor authentication on registrar, hosting and email admin accounts.
- Keep billing in your name for domains and core services, so renewals do not lapse if a relationship ends.
- Record everything in a simple asset register: what exists, where, who has access and when it renews.
If you use a managed provider for hosting, it is reasonable for the server to sit in their infrastructure. In that case, the contract should guarantee you full backups and help migrating if you leave.
Code ownership and intellectual property
Code ownership is defined by your contract, not by who paid for the work. Typical arrangements:
- Full assignment: All custom code becomes yours on final payment.
- Licence: The agency keeps ownership but grants you a perpetual licence to use and modify.
- Mixed: Custom work is assigned to you; the agency's reusable framework or engine is licensed.
The mixed model is common and fair. Agencies that build on their own engines, such as a CMS or e-commerce core, reuse them across clients, which reduces cost and improves quality. What you need is clarity on:
- Whether you can keep using the platform if you stop working with the agency
- Whether another developer can maintain it
- Whether you can export all content and data in a usable format
Have a lawyer review the IP clause for significant projects. Our guide on hiring a web development agency lists the ownership questions to ask before signing.
Key takeaway: Ownership is about control of accounts and clarity in contracts. If your company is the registrant, account owner and licence holder, any handover becomes a routine task instead of a crisis.
What a clean website ownership handover includes
When you move between providers, or bring work in-house, a complete handover package should include:
Access
- Domain registrar login or transfer authorization
- DNS management access
- Hosting control panel and server access (SSH or equivalent)
- Code repository with full history
- Admin accounts for the website itself
- Third-party service accounts or transfers
Data
- Full database export
- All media and uploaded files
- Configuration files with secrets handled securely
- Recent backups and backup schedule details
Documentation
- System overview: platform, versions, main modules
- Setup instructions for a development environment
- Deployment process and any automation
- Integrations: what connects to what, with credentials stored securely
- Scheduled tasks, queues and cron jobs
- Known issues and pending work
- Renewal dates for domains, certificates and licences
Knowledge transfer
A one or two hour call between outgoing and incoming teams, with someone from your business present, resolves questions that documentation misses.
A step-by-step handover process
- Review the contract for notice periods, handover obligations and outstanding payments.
- Inventory your assets using the table above.
- Secure access to the registrar, hosting and email before announcing changes.
- Take independent backups of code, database and files.
- Request the handover package in writing, with a deadline.
- Have the new provider verify they can deploy the site from the repository and backups.
- Rotate passwords and API keys once the transition is complete, and remove old provider access.
- Update DNS, monitoring and billing contacts as needed.
- Plan the migration window if hosting is moving, with a rollback option. Our website migration services handle this end to end.
Keep the tone professional. Most outgoing providers cooperate when requests are clear, reasonable and in line with the contract.
When things are not clean
Sometimes a previous developer is unreachable, or access was never documented. Practical recovery steps:
- Domain: Contact the registrar with proof of company ownership. If the domain was registered by the developer personally, recovery may require their cooperation or a formal dispute process.
- Hosting: Hosting providers can often transfer accounts with proof of payment and identity.
- Code: If no repository exists, the live server files are the starting point. Take a full copy immediately.
- Security: Assume old credentials may be compromised. Change passwords and check for unknown admin users.
A security review after a messy handover is worthwhile. See our website security checklist.
A quick self-audit
Answer these questions today. Any "no" or "not sure" is worth fixing:
- Is our company the registrant of every domain we use?
- Do we know when each domain and SSL certificate renews?
- Can someone in our company log in to the hosting account without asking a supplier?
- Do we have a recent backup of the database and files stored outside the live server?
- Can we access the code repository and its full history?
- Are payment gateway, analytics and email marketing accounts registered to our company?
- Do we have a list of everyone who currently has admin access?
- Does our contract state who owns the code and what happens if we leave?
Ownership and ongoing maintenance
Owning your website does not mean doing everything yourself. Many businesses keep full ownership while a provider manages updates, backups and monitoring. The difference is that the provider works inside your accounts, under a contract that defines responsibilities and exit terms.
Next steps
A ten-minute audit of who controls your domain, hosting, code and data can prevent weeks of stress later. At DigiVort, clients own their domains, data and custom code, and we provide documented handovers when work moves in-house or elsewhere. If you need help auditing your current setup or moving from another provider, start with our project wizard or see our maintenance and support plans.
