Website handover: what your business should be able to do after launch.

Launch changes the team's responsibilities

A new website is online and looks right in the demonstration. The next week, a colleague needs to update a service, the enquiry recipient changes, and an account renewal arrives in a former supplier's inbox. These are ordinary operating situations. Handover should prepare your business for them, with clear access and instructions matched to the website you actually received.

1. Confirm control of the essential accounts

Create an account register for the domain, hosting or platform, business email, analytics, search tools and any services used by the website. Record the organisation that controls each account, the responsible person, renewal ownership and a recovery contact. Where a supplier manages a service, state the arrangement and the route for transferring it.

Have the nominated business owner demonstrate access through the intended method. Use individual access where the service supports it rather than treating a shared password document as the complete handover. Keep recovery details in an appropriate secure location, separate from a public project folder. The aim is operational control, not a large attachment nobody understands.

2. Practise the edits your team will make

Ask a staff member to change a realistic piece of content in the agreed editing environment: a service description, a team profile or a delivery-area note. Include both Arabic and English versions when the site has them. Let the staff member perform the task while the supplier observes; watching a developer click through the editor does not establish that the business can use it.

Agree which changes staff can make safely and which require development. A website need not expose every layout setting to be maintainable. Clear boundaries, a short guide and a safe way to review content can be more useful than unrestricted access to every control.

3. Run acceptance checks that cross the whole journey

Choose checks based on the agreed scope. Follow an enquiry from the website to its destination and confirm receipt. Check the main navigation, mobile layout, keyboard operation and language switch. Open important old addresses and any advertised downloads. For a store, include the relevant product, shipping and payment scenarios in an agreed test arrangement.

For example, a fictional bilingual consultancy might accept the contact journey only after its administrator receives an Arabic test request, can identify the requested service and knows who will handle it. Record the check, its result and any unresolved item with an owner. Visual approval is one part of acceptance, not the whole record.

4. Agree how recovery actually works

Ask what is backed up, where it is stored, how often it runs and who can restore it. Different platforms offer different recovery options; document the arrangement for yours. A backup indicator is useful, but an agreed restore exercise provides stronger evidence that the procedure is understood. For WordPress specifically, the official handbook distinguishes the database from site files, both of which matter to a complete recovery plan. See the WordPress backup guidance.

Also record how to report a serious fault, who decides whether to pause a feature, and what information the support person needs. Keep these instructions accessible when the website itself is unavailable.

5. Define the work that follows handover

Separate correction of an agreed delivery defect from a new request, routine maintenance and a third-party service problem. State the support period, covered systems, contact route and response hours. A response commitment explains when someone will acknowledge or assess an issue; it should not quietly become a guarantee that every issue will be resolved within that time.

Before closing the project, ask one practical question: could the named person run the ordinary website tasks next week without reconstructing the project from chat messages? If not, complete the missing access, practice or instructions. See how Sabbk scopes website delivery and continuing care. Handover should leave responsibility understandable on both sides.