A website can be beautifully designed and technically impressive while leaving its owner dependent on a single developer for access, updates or recovery.
This problem often goes unnoticed until something goes wrong. A business needs to change its hosting provider, update an important page, recover from a technical failure or appoint a new developer, only to discover that it cannot access the relevant accounts or files.
For a small business, that can create unnecessary delays and expense.
Whether your business operates in Maboloka, Soshanguve, Centurion or elsewhere in South Africa, website ownership should be considered part of the development project from the beginning. A successful handover means more than receiving a link to the finished website.
It means knowing what you own, where the important assets are managed, who has access and how the website can be maintained if circumstances change.
1. Confirm who controls the domain name
Your domain name is the address customers use to reach your website. It may also be connected to business email, verification records and other online services.
Before accepting a website handover, establish:
- Which registrar manages the domain.
- Which account is authorised to manage it.
- Who can renew the registration.
- Who can change its domain name system (DNS) records.
- Which payment method is used for renewals.
- When the next renewal is due.
- Which recovery email address and telephone number are registered.
The business should have appropriate control of the domain account, even when a developer performs technical administration on its behalf.
Avoid relying exclusively on a developer's personal email address or an account that nobody else in the business can access.
Domain control is particularly important when the domain also supports business email. Incorrect DNS changes can affect both the website and the ability to send or receive messages.
Practical check: Sign in to the domain provider's account and confirm that the business can see the domain, renewal information and relevant management settings.
Do not change DNS records casually just to test access. Record the current configuration and understand the consequences before making changes.
2. Identify the hosting account and deployment process
Hosting is the environment or service used to make the website available online. The arrangements vary: a website might run on shared hosting, a managed platform, a content delivery network or a cloud deployment service.
Ask the developer to document:
- The hosting or deployment provider.
- The account that owns the project.
- The production website's deployment location.
- How new versions are published.
- Where environment variables and configuration are managed.
- How access is granted to authorised staff.
- Which services incur recurring charges.
- What happens if the hosting account is suspended or the service becomes unavailable.
Some platforms connect directly to a source-code repository and deploy automatically when approved changes are published. Others require a manual upload or deployment process.
The business does not necessarily need to perform deployments itself. It does need to understand the arrangement and have an agreed way to request changes or transfer responsibility.
If a third party manages the hosting account, clarify what happens when the service relationship ends. Confirm which assets can be transferred and whether any platform-specific restrictions apply.
3. Obtain the source files and technical documentation
A published website is not always the complete project.
Depending on the technology, the working project may contain source code, images, configuration files, content, build instructions, database definitions and other resources.
Ask which files and assets are included in the handover.
For a custom website, the handover may include:
- A source-code repository or an agreed source archive.
- Instructions for installing dependencies and running the project.
- Build and deployment instructions.
- Configuration documentation.
- A list of external services and integrations.
- Database backup and restoration instructions, where applicable.
- A record of important technical decisions.
- Details of any known limitations or outstanding work.
Not every website needs a complex technical manual. The objective is to provide enough information for another competent person to understand and maintain the project.
If the website uses a framework, make sure the relevant project files are included rather than receiving only the final compiled output when the agreement calls for source files.
Also confirm which third-party packages, themes, plugins, fonts, images and other assets are used, and review any applicable licences or usage restrictions.
Do not assume that paying for website development automatically transfers every third-party licence or every asset used in the project. Ownership and usage rights depend on the contract, applicable law and the terms of the relevant assets.
4. Check who owns the important accounts
A website may rely on several services beyond its domain and hosting provider.
Examples include:
- Google Search Console.
- Website analytics.
- Form processing or enquiry delivery.
- Email delivery services.
- Content management systems.
- Online payment providers.
- Booking systems.
- Security and backup services.
- Stock image or font libraries.
Create an account register that identifies each service, its purpose, the account owner, the people with access and the renewal or billing arrangements.
The register does not need to contain passwords. Store credentials in an appropriate password manager and use individual accounts and permissions wherever the service supports them.
Google's Search Console ownership and permissions guidance explains the distinction between owners and other users. Owners have greater control over property settings, user access and available tools.
Make sure the business has suitable access to its own Search Console property. If an external developer or agency manages the property, agree on the appropriate access level and how that access will be maintained.
Avoid sharing a single login between several people when individual permissions are available.
5. Verify analytics and search tools
If the website uses analytics or search reporting, check that the business can access the relevant accounts and understand what they measure.
For Google Search Console, confirm that:
- The correct website property is present.
- An authorised business representative has suitable access.
- Important website versions are represented appropriately.
- The sitemap can be identified, where one is used.
- Any known indexing or verification issues are documented.
For analytics, confirm which property or account collects the data and who can manage it. If conversion tracking is configured, establish which actions are measured and whether those events have been tested.
Do not assume that the presence of an analytics script proves that all important actions are being tracked correctly.
A new developer should be able to determine which tools are connected without having to reconstruct the entire setup from scratch.
6. Establish a backup and recovery plan
A backup is useful only if the business can retrieve it and restore the necessary information.
The right backup arrangements depend on the website. A static information site may primarily require source files and configuration. A database-driven application may also require database backups, uploaded files and a documented restoration process.
Ask:
- What is backed up?
- How frequently are backups created?
- Where are they stored?
- Who can access them?
- How long are they retained?
- How would the website be restored?
- Has the restoration process been tested?
Do not keep the only backup in the same account that contains the live website if a failure of that account could also remove the backup.
Protect backup files because they may contain source code, configuration information or personal information. Apply suitable access controls and retention practices.
A simple restoration test can reveal problems that a successful backup notification cannot. Test in an appropriate environment so that the exercise does not disrupt the live website.
7. Review security and access permissions
Website handover is an opportunity to remove unnecessary access and confirm that important accounts are protected.
Review:
- Administrator and developer accounts.
- Hosting and deployment permissions.
- Domain and DNS access.
- Repository permissions.
- Content management accounts.
- API keys and other credentials.
- Third-party service access.
- Multi-factor authentication options.
- Recovery procedures.
Remove access that is no longer required, following an agreed handover process. If a departing developer's credentials or tokens are embedded in the project, arrange for the relevant credentials to be rotated safely.
Do not simply delete accounts without checking whether they own important services or contain the only copy of a necessary verification token.
Security also includes keeping software and dependencies maintained. Identify who is responsible for updates and what happens when an update introduces a problem.
8. Confirm that forms, email and integrations work
A website is not ready for handover merely because its pages load.
Test the actions customers are expected to complete.
For a typical service website, this might include:
- Submitting an enquiry form.
- Confirming that the submission reaches the intended recipient.
- Checking that the customer receives the correct confirmation.
- Testing telephone and messaging links.
- Confirming that important navigation links work.
- Checking any booking or payment integration.
- Testing the website on mobile and desktop.
- Verifying that error messages are understandable.
If the website sends email, document the service responsible for delivery and the configuration needed to maintain it. An enquiry form that silently fails can cost a business opportunities even when the rest of the website appears healthy.
Test the complete journey from the visitor's perspective rather than checking only the technical response from a form endpoint.
9. Record the website's content and usage rights
A website can contain text, photography, illustrations, icons, fonts, videos and other material obtained from different sources.
Record the important assets and the terms under which the business can continue to use them.
Questions to resolve include:
- Was the content supplied by the business or created as part of the project?
- Are there third-party assets with licence conditions?
- Are any subscriptions required to continue using particular assets?
- Can the business edit and republish the content?
- Are there restrictions on transferring assets to a replacement website?
- Are customer photographs or testimonials used with appropriate permission?
The agreement with the developer should explain the ownership and permitted use of project deliverables. Where third-party services or assets are involved, the agreement should distinguish those materials from work created specifically for the business.
Keep original business documents and media in a location the business can access independently of the website deployment.
10. Create a concise handover register
A practical handover register makes it easier to maintain the website after the original project is complete.
| Item | What to record | Handover check |
|---|---|---|
| Domain | Registrar, account owner, renewal date | Business can access the account |
| Hosting | Provider, project, billing owner | Deployment and billing arrangements are understood |
| Source code | Repository or source archive | Files can be accessed and maintained |
| DNS | Current records and purpose | Configuration is documented |
| Search tools | Search Console and relevant properties | Appropriate business access is confirmed |
| Analytics | Property and event configuration | Reporting access and purpose are understood |
| Integrations | Service, account owner and dependencies | Important customer journeys are tested |
| Backups | Scope, frequency, storage and retention | Restoration process is documented |
| Security | Users, permissions and credential rotation | Unnecessary access is addressed |
| Licences | Third-party assets and terms | Continued use is understood |
| Maintenance | Responsibilities and escalation process | Ownership after launch is clear |
Store the register somewhere authorised business staff can find it. Avoid putting passwords, private keys or other secrets directly into the register.
11. Agree on ongoing support and exit arrangements
Before the project closes, clarify what support is included and what requires a separate agreement.
Establish:
- How to report a problem.
- Who responds to urgent failures.
- What types of changes are included in support.
- Whether hosting or other recurring services are billed separately.
- How changes are approved.
- What happens if the relationship ends.
- How files, accounts and outstanding tasks are handed over.
Do not rely on assumptions about free updates or indefinite support. Record the actual agreement.
For a business serving Maboloka, Soshanguve, Centurion or surrounding communities, the most appropriate arrangement may be one in which the business handles routine content while a developer manages technical changes. Another business may prefer to outsource most ongoing maintenance.
Either model can work when responsibilities are clear.
CTA — Website development
Planning a new website or a rebuild? Explore Mogen's web development service and consider the technical, content and ownership requirements your project should address.
Frequently asked questions
Does the business need to own the hosting account?
Not in every arrangement, but it should understand who controls the hosting, how access is managed and how the website can be transferred or recovered. The contract should make the responsibilities clear.
Should a developer provide the website's source code?
That depends on the technology and the agreed scope. For custom development, clarify which source files and project assets are deliverables, how they will be supplied and what rights the business receives.
Can I change developers after launch?
Usually this is possible, but the effort depends on the architecture, account access, documentation, licences and transfer arrangements. A clear handover reduces avoidable friction.
Is a website backup enough to guarantee recovery?
No. The business needs the correct files and data, access to required services and a workable restoration procedure. Test the recovery process rather than assuming that a backup is sufficient.
CTA — Discuss your website requirements
If you are preparing a website project or need help clarifying its requirements, contact Mogen to discuss the work and the handover expectations that matter to your business.
Conclusion
A website handover should leave the business with a clear understanding of its digital assets, access arrangements, maintenance responsibilities and recovery options.
Domain access, source files, account permissions, tested forms, backups and documented support arrangements all contribute to a more manageable website.
Whether your business serves Maboloka, Soshanguve, Centurion or customers elsewhere in South Africa, plan for ownership and continuity before the project closes. It is far easier to clarify these details during development than to reconstruct them during an emergency.