Domain, hosting and content: which access should you receive at handover?

Receiving your website address and an account for editing copy does not explain the whole management arrangement. Domain, hosting, content and connected services may rely on different accounts. Handover needs to make that organisation understandable to the people taking responsibility.

The objective is not to collect every possible login indiscriminately. It is to check that the business has the access it needs, that responsibilities are known and that another person can continue under the agreed conditions. A tested inventory is more useful than an unexplained collection of passwords.

Prepare the inventory before the final meeting

Ask for the services list once the project configuration is known. For each service, record its name, purpose, relevant account, owner and the type of access intended for your company. Update the list as project choices become definite.

Explain what the business manages directly and what remains delegated. You can entrust a technical operation to somebody else while knowing the contact and takeover arrangements. Clear delegation is different from an account whose relationship with the organisation nobody understands.

At handover, use the inventory for verification. Give each item a status: received and checked, supplied but untested or still needing clarification. This avoids treating an invitation that nobody has used as proof of working access. It also gives unresolved questions somewhere visible to remain.

Domain name: identify its management account

The domain is the address used to reach your website. Ask which provider holds its registration and which account is used for administration. Identify who receives communications and who follows the relevant renewal dates on behalf of the business.

ICANN emphasises keeping domain contact information current. Official FAQ on registration contact details.

At delivery, check the information your organisation needs: the domain concerned, contact, intended access and renewal process. Someone in the company should know where to find these details even when daily administration is delegated to a specialist.

If the account was created in a way that does not match the intended organisation, agree how to regularise the situation with the relevant provider. Follow that service’s procedures with authorised people and keep a record of the arrangement reached. Clarify the actual position before assuming a transfer has taken place.

Domain configuration and associated services

The registration account and the place where domain settings are managed are not necessarily the same interface. Ask where that configuration is held and who can administer it. The inventory should make this relationship between services visible.

Identify associated uses: the main website, any relevant subdomains and email where applicable. A future website change should be prepared with an understanding of the other uses involved. Receiving access is first a verification of how those responsibilities are organised.

Keep an explanation of responsibilities rather than an unexplained copy of settings. A later specialist will need to know who coordinates these services and which scope may be changed after agreement. This context makes the information useful when a genuine intervention is required.

Hosting: understand where the website operates

Ask which service hosts the website and how the company reaches the information needed to follow it. Depending on the solution, this may be a hosting account, a project within a platform or an environment operated on your behalf.

Clarify permission levels. Viewing project information, following billing and modifying configuration are different capabilities. The supplied access should match agreed tasks and identify the people able to act on other matters. A familiar platform name does not explain those responsibilities by itself.

Ask about future takeover arrangements: what another provider would need, where those elements are held and who prepares them. The answer should match the actual solution rather than rely on a broad statement that the website can be recovered. Request an understandable description of the expected outcome.

CMS: check the rights actually supplied

The person who will use content management should test their access. They need to locate a page, understand its fields and perform a representative task within the agreed checking process. A successful sign-in is only the beginning of this verification.

Separate editorial permissions from administration. Somebody may be allowed to edit articles without managing other users. The company should know who holds the responsibilities needed to organise access and introduce a new editor when the team changes.

Check specific content such as projects, services, languages and elements reused across pages. An account does not demonstrate that everything described as editable can actually be managed. The exercise should cover the delivered scope rather than a convenient sample unrelated to future work.

Files and code: specify what is transferred

Ask which project files are supplied under the agreement: content, visual assets, specific components, documentation or access to a code repository when part of the solution. Clarify their organisation and version so they can be recognised later.

If a repository is included, an authorised person should be able to locate it and identify the website it belongs to. Another specialist will also need appropriate working instructions: project structure, preparation process and relationship with publication, according to the arrangement used.

Do not confuse a page export with complete takeover of every function. Some elements may depend on another service. The handover record should explain those relationships so the company knows what it receives and what could need further work during a later change.

Media: receive usable material

For images, video and other media, ask which files are included and how they are used. Published versions and production material may serve different purposes. Their organisation should make that distinction clear rather than leaving future editors to guess which file is appropriate.

Ask for the intended usage conditions of third-party material and the location of the relevant information. Someone preparing a later publication should understand which material is intended for which use without reconstructing the original selection process or contacting every contributor again.

Animated sequences deserve their own explanation. Where are the files, how do they connect to the site and which changes are ordinary editing tasks? A caption that can be edited and a sequence requiring reconstruction should be identified separately in the handover.

Forms and connected tools

Follow a representative enquiry from the website to its destination. Which account receives the information? Who can view it? Which tool produces the expected response? These questions often reveal access requirements that do not appear inside the CMS.

In a fictional example, a restaurant uses an external reservation service. The business needs to understand the relationship between the website link, the reservation account and the person handling requests. The content owner and operational owner may be different people with different tasks.

Add other tools actually used, such as enquiry management, statistics or content distribution, according to the project. Request relevant, agreed access rather than multiplying accounts without a purpose. The aim is to follow the real operation and know where information can be found.

Backups and restoration arrangements

Ask where planned backups are held, who follows them and who can organise restoration. Saying that backups exist does not explain their coverage or how they would be used. The company should know the responsible person and the next step if help is needed.

Clarify the scope: content, files, data and configuration as applicable. Identify information held in separate tools as well. The handover documentation should make responsibilities understandable when several services contribute to the complete website experience.

Useful verification includes an explanation of the process and contacts. Technical restoration exercises should be organised in an appropriate environment by those responsible. Downloading a file without understanding its purpose does not by itself demonstrate a usable recovery arrangement.

Use a simple handover table

Your inventory can follow this format without containing secret credentials:

Add a column for open questions and the person resolving each one. An incomplete item should remain visible until clarified. The table records an actual transfer of capability rather than creating the appearance that every part is already complete.

Finish with a practical takeover exercise

Ask the future owner to find a routine piece of information, identify the relevant account and explain the next action. A second person can check whether the documentation is understandable without having attended all project discussions. This reveals whether the record stands on its own.

The exercise exposes unclear names, unaccepted invitations and implicit responsibilities. Complete missing information while project participants are available and the configuration remains familiar. It is easier to resolve a specific question now than reconstruct the whole arrangement after a staff change.

Keep the inventory current after later changes. Replacing a service or changing the responsible person should update the record as well as the live setup. A handover document is most useful when it remains a working reference rather than a snapshot nobody can rely on again.

To prepare delivery with MV Design, identify the people taking over content and those following the supporting services. We can organise a handover list suited to how your project actually operates.