Website Handover Checklist: Details to Collect from a Web Development Company
Your website may be live, generating leads, and looking exactly the way you want, but that doesn’t necessarily mean your business fully owns it.
What happens if you decide to change web development companies tomorrow? Can you access your domain, hosting, website files, database, analytics, integrations, backups, and third-party accounts without asking your current developer?
If the answer is no, you may have a website that works, but not a website you completely control.
A website handover is about more than receiving a CMS login. After your website development is complete, It is time to make sure your business has the access, credentials, files, documentation, and ownership information needed to run, maintain, secure, and migrate the website independently.
Below is a checklist for you to request your web development company while they hand over your website.
Table Of Contents
| 1. | Introduction |
| 2. | Domain & DNS Access |
| 3. | Hosting & Server Access |
| 4. | Website Files & Database |
| 5. | CMS & Administrative Access |
| 6. | Third-Party Services & Integrations |
| 7. | SEO Tools, Configurations, and Assets |
| 8. | Email & Communication Systems |
| 9. | Security & User Access |
| 10. | Technical Documentation |
| 11. | Backup & Recovery |
| 12. | FAQ |
| 13. | Conclusion |
| 14. | Ready to Take Control of Your Website? |
1. Domain & DNS Access
The domain name is the address customers type in the browser to reach the website. If domain names are registered under the web development agency, the business may lose ownership of the website address.
During handover, the business should receive the following:
- Domain registrar account and login
- Domain ownership and registrant information
- Renewal and billing information
- Domain expiration date
- Nameservers
- Current DNS records
- DNS management access
- Domain transfer or authorization information, where applicable
Suppose your agency registered yourbusiness.com using its own registrar account. You may be able to manage the website, but if the agency controls the registrar, they still control the domain itself. If the relationship ends, transferring the domain could become unnecessarily difficult.
2. Hosting & Server Access
If the domain is your website’s address, hosting is where the website actually lives. A complete handover therefore requires control of both.
Collect:
- Hosting provider and account details
- Hosting account access
- Control panel access, such as cPanel or equivalent
- Server credentials
- FTP/SFTP access
- SSH access, where applicable
- Database access
- Server and environment details
- Backup system information
- SSL certificate and management information
- CDN access, if applicable
For instance, the company may receive a CMS admin dashboard but not have access to the server. In this case, the business will always rely on the web development agency to make any changes on the website.
An easy way to distinguish assets is given below:
| Asset | What it controls |
|---|---|
| Domain | Where customers find your website |
| DNS | How that domain connects to online services |
| Hosting | Where your website runs |
| CMS | Where you manage website content |
Make sure your business can access the hosting environment independently and knows where the website, database, backups, and SSL configuration are managed.
3. Website Files & Database
Access to the CMS area is not enough for full website ownership. The business should also receive the website’s files and database if it wants to change the hosting or development agency.
In case of migration, the company will benefit from having a duplicate of the website that can be used for testing or storing data. As for the files, their content depends on the development technology:
Website files
Depending on your technology stack, these may include:
- HTML files
- CSS files
- JavaScript files
- PHP or other server-side code
- Theme files
- Plugin or module files
- Images and other media
- Custom code
- Relevant configuration files
Database
The database may use technologies such as MySQL, PostgreSQL, MongoDB, or another database system.
For a WordPress website, for example, the database contains important information such as pages, posts, users, settings, and other site data.
Imagine your company changes development agencies. The new developer needs to recreate the website on a new server, but the previous agency only provides a CMS login. Without the underlying files and database, the migration may become much harder, or require the old agency’s continued involvement.
For a website migration, aim to have a complete, usable copy of the website files and database, along with instructions for restoring them where necessary.
4. CMS & Administrative Access
Whether your website runs on WordPress, Shopify, Drupal, Magento, or another CMS, your business should have administrative control over the platform.
For example, a WordPress handover should account for:
- Administrator account
- User account list
- Theme access
- Plugin access
- CMS settings
- Relevant billing or subscription information
- Custom functionality documentation
But don’t make the common mistake of treating a username and password as proof of ownership. Access and ownership are not the same thing.
If the CMS account was created using the developer’s email address, recovery information, payment details, or authentication method, the developer may still have control over the account.
Whenever possible, make sure critical accounts are registered under your company’s email address and billing information, with your organization controlling recovery and multi-factor authentication.
5. Third-Party Services & Integrations
A modern website hardly uses one system to function. It normally uses several web services related to analytics, marketing, security, communication, and others. A business should know which services it uses and have administrative access to them.
Below are the popular categories and the assets listed under them.
| Category | Examples of assets to check |
|---|---|
| Analytics | Google Analytics, Google Tag Manager |
| Search | Google Search Console, Bing Webmaster Tools |
| Marketing | Email platforms, CRM, marketing automation |
| Infrastructure | CDN, Cloudflare, SSL, external APIs |
| Payments | Payment gateways and merchant accounts |
| Communication | SMTP and transactional email services |
| Forms | Form tools, lead-routing systems |
| Integrations | CRM, ERP, booking, inventory, or other APIs |
You need to know who owns the account, who pays for it, who can access it, and whether the website depends on it to function.
6. SEO Tools, Configurations, and Assets
Website visibility in search engines is vital for the company, and a handover should not impact it. That is why the business should receive a complete set of SEO-related assets during handover.
Collect and document:
- Google Search Console access
- Google Analytics access
- Google Business Profile access, where relevant
- XML sitemap information
- Robots.txt configuration
- Existing redirect list
- Canonical configuration
- Meta title and description configuration
- Structured data/schema implementation
- SEO plugin configuration
- Existing keyword and ranking data
- Backlink information, where available
The goal is to make sure a new development team can understand the website’s existing SEO setup rather than rebuilding it from scratch. Suppose your existing website has:
/services/web-development
and you migrate the site to:
/services/web-development-services
If the old URL isn’t properly redirected, visitors and search engines may encounter a 404 page. The visitors and search engines will see these as two different websites, resulting in loss of traffic and SEO value.
That’s why a website migration should preserve important URLs, redirects, metadata, structured data, and other existing SEO signals wherever possible.
Before and after a migration, compare important URLs, indexation, redirects, rankings, organic traffic, and other relevant SEO metrics.
7. Email & Communication Systems
A website may look perfect, but it will cease to function if something is wrong with the communication tools. For example, after handover, a contact form on the website may stop working due to incorrect email settings.
For example, a customer might submit a contact form successfully, but the business never receives the enquiry because the email service or SMTP configuration was not transferred correctly.
During handover, identify:
- Business email accounts connected to the website
- SMTP provider
- Email sending service
- Contact form configuration
- Transactional email configuration
- Notification settings
- SPF records
- DKIM configuration
- DMARC configuration, where applicable
This is particularly important for websites that send order confirmations, booking notifications, password-reset emails, lead alerts, or other automated messages.
Submit a test form, trigger relevant automated emails, and confirm that messages reach the intended recipients. Don’t assume that because the website loads correctly, its email infrastructure has been transferred correctly too.
8. Security & User Access
A handover also creates an opportunity to clean up who can access your website and its supporting systems.
Your business should know:
- Who has CMS administrator access
- Which developer accounts exist
- Who has hosting/server access
- Who has database access
- Which API keys and tokens are active
- Which third-party services have access
- Where backups are stored
- How multi-factor authentication is configured
- Which accounts use shared credentials
Once the handover is done, the company should revoke all unnecessary permissions and remove all inactive accounts to improve security. If possible, it is better to change passwords for all accounts, especially if several people had access to them. The handover does not mean that all systems are available for everyone.
A successful handover should leave your business with known, controlled, and appropriate access, rather than simply giving more people access to the same systems.
9. Technical Documentation
Credentials tell you how to access the website.The company should receive technical documentation because it tells you how the website works. Ask the development company to provide documentation covering:
- Technology stack
- CMS and version
- Hosting architecture
- Custom functionality
- Theme and plugin/module list
- API integrations
- Third-party dependencies
- Deployment process
- Backup process
- Maintenance requirements
- Known issues
- Custom code documentation
- Important configuration details
A new development agency will not be able to quickly figure out how this integration works. Hence, the previous agency should describe the integration clearly in the technical documentation to help the new agency maintain the system.
10. Backup & Recovery
Sometimes, a company forgets about the importance of website backups. It is critical to know whether the website is backed up, where the backups are stored, who has access to them, how often the backups are made, and how to restore the website from the backups.
It is always a good idea to request the latest backup of the website, including files and database, to test it. For example, if a web development agency informs the company that the website is backed up on a daily basis, but the backups are stored on the agency’s server, where the company does not have access; the company will not have control of the backups.
Ask for:
- Latest full website backup
- Database backup
- Website file backup
- Backup location
- Backup schedule
- Backup retention period
- Restoration procedure
- Access to the backup system
For example, a development agency may tell you that your website is backed up daily. But if those backups are stored in an account controlled entirely by the agency, your business may still have limited control over its recovery process.
If possible, verify the restoration process before the handover is considered complete.
FAQ:
Ask for access to your domain, hosting, CMS, website files, database, third-party services, analytics, SEO assets, email systems, backups, and technical documentation.
No. CMS access is only one part of ownership. You should also control the domain, hosting, website files, database, integrations, backups, and other critical accounts.
Ideally, the business should own and control the domain registrar account, billing information, renewal details, and DNS management rather than leaving these entirely with a development agency.
Yes, particularly if you may change hosting providers or development companies. A complete copy of the files and database makes future migration, restoration, and maintenance easier.
Check your domain and DNS, hosting, files, database, redirects, URLs, SEO configuration, analytics, integrations, forms, email systems, SSL, backups, and third-party services before the migration.
Conclusion
A website handover is complete only when your business can independently access, manage, secure, maintain, and recover its website. That means looking beyond the CMS login and checking your domain, hosting, files, database, third-party services, SEO assets, email systems, security, documentation, and backups.
If the company plans to migrate the website in the future, it should collect the above-mentioned assets. A properly completed handover will allow unrestricted access to the website for the company while ensuring its security. It will also give the company an opportunity to migrate the website without losing any critical assets.
Now it is easier to choose the right website development partner who cares about the long-term success of the business and its website.
Ready to Take Control of Your Website?
A website should be built for your business, not locked to the developer who created it. Our website development services focus on building websites with clear ownership, scalable architecture, reliable integrations, and maintainable technology from the start.
Whether you’re building a new website, rebuilding an existing one, or planning a migration, we can help you create a stronger digital foundation that’s easier for your business to manage and grow.