A website launch is an important milestone, but it should not be the end of the development process.
Once a website is live, someone must be able to manage its domain, understand its hosting arrangements, renew the services it depends on, recover from technical problems and make future changes.
These responsibilities can become difficult when a business receives a website without adequate documentation or discovers that essential accounts are controlled by someone who is no longer available.
This is not necessarily a problem with the website itself. It is a problem with the handover.
Whether your business operates in Maboloka, Soshanguve, Centurion or elsewhere in South Africa, a structured website handover can reduce avoidable disruption and make future maintenance easier.
This guide explains what to request from your developer, which responsibilities to clarify and how to check that your business is prepared to manage its website after launch.
1. Confirm who controls the domain name
Your domain name is the address customers use to reach your website. Losing access to its registration account can make it difficult to renew the domain, update its settings or move it to another provider.
Before the handover is considered complete, establish:
- Which registrar manages the domain.
- Who is listed as the registrant, where applicable.
- Which account is used to manage registration and renewal.
- When the domain expires or renews.
- How renewal notices are delivered.
- Who can authorise a transfer or changes to the domain.
- Where recovery information is stored.
The business should understand its contractual rights and have an appropriate route to manage its domain independently of the developer.
The exact registration arrangements depend on the domain extension, registrar and applicable terms. For example, ICANN explains the role of registrants and registrars for domain registrations within its remit; South African .co.za domains have their own relevant registry and registrar arrangements.
See ICANN's explanation of the domain registration process.
Important: Paying for a domain does not, by itself, prove that the business controls the account through which it is registered. Verify the actual registration and account arrangements.
2. Document hosting and infrastructure access
A website needs somewhere to run. Depending on its architecture, that could involve traditional web hosting, a cloud hosting platform, a content delivery network or several connected services.
Request a clear record of the infrastructure used by your website.
At minimum, document:
- The hosting provider and account owner.
- The website's production URL.
- The hosting plan or relevant subscription.
- Where DNS settings are managed.
- How deployment or publishing works.
- Where environment configuration is maintained.
- Which recurring charges apply.
- Who receives service notifications.
- How to contact the provider for support.
Do not assume that every website has a conventional hosting control panel. A modern application may be deployed from a source-code repository to a managed hosting platform, while a simpler website may use a shared hosting account.
The handover should describe the actual arrangement rather than forcing it into a generic checklist.
Avoid requesting that passwords be sent in an ordinary email or placed in an unprotected document. Access should be transferred through an appropriate secure method, and unnecessary access should be revoked when the transfer is complete.
3. Establish access to the website itself
The access required depends on how the website is built.
A content-managed website may have an administration area. A custom-developed website may instead depend on a code repository, deployment platform and configuration managed by a developer.
Ask which of the following apply:
- Website administration account.
- Content management system access.
- Source-code repository access.
- Deployment platform access.
- Database administration access, if applicable.
- DNS management access.
- Domain registrar access.
- Relevant third-party service accounts.
Not every employee needs access to every system. Give each person only the permissions needed for their responsibilities.
The business should nevertheless have an agreed process for obtaining authorised access if its normal developer or administrator becomes unavailable.
If the developer uses their own account to deploy the site, clarify how the project can be transferred or administered without depending indefinitely on that individual account.
Do not copy production passwords into a handover document merely for convenience. Record the account names, ownership, recovery procedures and secure transfer arrangements instead.
4. Obtain the appropriate project files and documentation
A website may include source code, design assets, images, fonts, configuration, content, database structures and deployment instructions.
The handover should identify what the business is entitled to receive and what it actually receives.
Depending on the agreement and technology, relevant items may include:
- Source code or an agreed repository.
- Final website assets.
- Approved copy and images.
- Design files, where included in the agreement.
- Content exports.
- Database exports, where applicable.
- Installation or deployment instructions.
- Configuration documentation.
- A list of required third-party services.
- A record of outstanding work or known limitations.
Ownership and access are not the same thing.
A developer may use third-party software, stock assets, licensed fonts or other components subject to their own terms. The business should not assume that every dependency can be transferred or redistributed freely.
Clarify intellectual property rights, licence restrictions and any continuing fees in the development agreement.
For custom applications, request enough technical documentation to make future maintenance practical. That does not mean every small project needs an extensive architectural report. A concise explanation of how the application is built, configured and deployed may be sufficient.
5. Check backup and recovery arrangements
A backup is useful only if it can be restored when needed.
Find out what is backed up, how frequently backups occur, how long they are retained and who is responsible for restoring the website.
Depending on the application, backups may need to cover:
- Website files.
- Databases.
- Uploaded documents and images.
- Configuration required to restore the service.
- Important content or application data.
A static website may have different backup requirements from an online shop or a custom application that stores customer records.
Ask whether backups are automatic, whether they are stored separately from the production environment and whether restoration has been tested.
Also clarify what the hosting provider does and does not cover. A hosting service may offer some recovery facilities, but that does not necessarily replace a business-specific backup and disaster-recovery plan.
Document who can initiate a restore, how to contact support and what level of disruption the business can tolerate.
6. Verify analytics and search access
If the website uses measurement or search tools, establish who controls the relevant accounts and where their data can be accessed.
These may include Google Analytics, Google Search Console and any other agreed reporting tools.
The handover should identify:
- Which tools have been configured.
- Which account or property represents the website.
- Who has administrative access.
- What events or conversions are being measured.
- Whether important forms or other customer actions have been tested.
- Where reports can be found.
- Whether the business can retain access if the developer relationship ends.
Do not assume that a website has functioning analytics merely because a tracking script appears in its code.
Test the actual configuration and verify that important events are recorded as intended.
For example, if the business relies on an enquiry form, confirm that a successful submission is recorded correctly without exposing unnecessary personal information.
Google Search Console provides information about search visibility, indexing and search traffic. Google Analytics focuses on activity measured after visitors arrive on the website. The tools have different purposes and should not be treated as interchangeable.
Google's documentation explains the distinction in Using Search Console and Google Analytics Data for SEO.
7. Review forms, email and integrations
A website may connect to services beyond its hosting platform.
Examples include enquiry forms, email delivery, booking systems, payment gateways, maps, customer relationship management systems and third-party APIs.
Create an integration register showing:
| Item | What to document |
|---|---|
| Service | Name and purpose of the integration |
| Account owner | Who controls the service account |
| Billing | Whether recurring charges apply |
| Configuration | Where relevant settings are maintained |
| Failure handling | How errors are detected and resolved |
| Data | What information is exchanged |
| Support | Who is responsible for maintenance |
For each important integration, test a realistic workflow.
Submit a test enquiry, confirm the expected notification arrives and verify that the information reaches the correct destination. If the site accepts payments or bookings, test the relevant workflow under appropriate conditions before declaring the system ready.
Avoid including live API keys, passwords or other secrets in the documentation. Record where configuration is maintained and how authorised administrators can manage it securely.
8. Request a maintenance and update plan
A website is not permanently finished when the initial build is complete.
Depending on the technology, it may require security updates, dependency updates, content revisions, compatibility testing, monitoring and occasional repairs.
Ask the developer to clarify:
- Which maintenance tasks are included in the agreement.
- Which tasks are the business's responsibility.
- Whether updates are automatic or manually applied.
- How urgent technical issues are reported.
- Whether maintenance work is charged separately.
- How changes are tested before production deployment.
- What support is available after launch.
- What happens when the agreement ends.
Do not assume that a website described as managed includes every possible change or emergency response. The actual scope should be documented.
If the business manages updates internally, assign responsibility to a named role and ensure that person has the skills and access required.
A maintenance plan should be realistic for the business's size and the website's complexity.
9. Test the website before signing off
A handover should include practical verification, not just a collection of documents.
Test the important customer journeys on mobile and desktop devices.
Confirm that:
- The main pages load correctly.
- Navigation and internal links work.
- Contact information is accurate.
- Enquiry forms submit successfully.
- Notifications reach the intended recipient.
- Important images and documents display correctly.
- The website uses HTTPS where required.
- There are no unintended development or maintenance notices.
- The live version is not accidentally blocked from search indexing.
- Analytics or other agreed integrations function correctly.
- The business knows how to report a problem.
For an existing website that is being replaced or moved, test redirects and important old URLs as well.
Google's site migration guidance recommends planning URL changes, checking redirects and monitoring the site after a move. These checks are especially important when a redesign also changes the domain or page structure.
Record unresolved issues and agree on how they will be handled. A transparent list of outstanding items is more useful than an assumption that everything is complete.
Mogen's Website Development
Planning a new website or preparing to replace an existing one? Explore Mogen's web development service to discuss project scope, launch requirements and ongoing responsibilities.
10. Prepare a simple website operations record
Once the handover is complete, keep a central record of the website's important operational details.
A useful record might contain:
| Record | Purpose |
|---|---|
| Domain and renewal information | Avoid missed renewals and access problems |
| Hosting and deployment details | Identify where the website runs |
| Account ownership | Clarify who administers each service |
| Backup and recovery plan | Explain how the website can be restored |
| Integration register | Track dependencies and recurring charges |
| Maintenance schedule | Establish responsibility for routine work |
| Technical documentation | Support future development |
| Support contacts | Help staff report problems efficiently |
| Outstanding issues | Keep unresolved work visible |
Store this information securely and keep it updated when services or responsibilities change.
Do not store shared passwords in an ordinary spreadsheet. Use an appropriate password manager and access-control process.
The objective is to make essential knowledge available to authorised people without exposing credentials or unnecessary personal information.
Frequently asked questions
Does the business always need the website's source code?
Not every website arrangement requires the same deliverables. The answer depends on the development agreement, technology and licensing terms. Establish what the business owns, what it is licensed to use and what it needs to operate or maintain the website.
Should a developer keep control of the domain?
A developer may help manage domain settings, but the business should understand the registration arrangements and have an appropriate way to manage its domain independently. The exact structure should be agreed in advance.
Is a backup included with hosting?
That depends on the hosting service and agreement. Confirm what is backed up, how long backups are retained and whether restoration has been tested. Do not assume that hosting alone provides a complete recovery plan.
How often should a website handover record be reviewed?
Review it whenever the domain, hosting, deployment process, integrations or responsible people change. A brief periodic review also helps identify expired services and outdated contact information.
Discuss your website requirements
If you need help planning a website project or clarifying what should be included in its handover, contact Mogen to discuss your requirements.
Conclusion
A website handover is about more than receiving a working URL.
The business needs to understand its domain, hosting, access arrangements, project deliverables, backups, integrations and maintenance responsibilities. It should also know how to test the website and whom to contact when something goes wrong.
These arrangements are easier to establish before a project is signed off than after an urgent problem occurs.
A clear handover gives the business a practical foundation for managing its website, working with future developers and making changes without unnecessary dependence on undocumented knowledge.