Website handover checklist Dubai: who owns the keys?

Three months after launch, a premium plugin licence expires. The person who built the site is on leave, the supplier account is not accessible, and nobody can say which card paid for the renewal. The website is still live, more or less, but a routine update has become an account-recovery exercise.

That is the sort of loose end a proper website handover should remove for a Dubai business. Launch approval is not the finish line if the company cannot control the domain, renew a licence, verify an enquiry, restore a backup or change a supplier without a bit of detective work.

A live site is not the same as a completed handover

A website handover checklist for Dubai should record every critical website asset, its business owner, the access route, renewal responsibility and recovery method. It should cover the domain, DNS, hosting, WordPress, source files, licences, analytics, forms, backups, documentation and post-launch support. The aim is simple: the business can operate, verify and recover the site without relying on one supplier or former employee’s memory.

It is worth treating this as part of the delivery work, alongside the build itself. A sensible website development project in Dubai includes the practical arrangements that let a business run what has been delivered, rather than merely admire the finished homepage.

Build a handover register before approval

The useful document is not a vague email saying that access has been sent. It is a handover register. One row per asset, with enough detail for someone else to take over calmly on an ordinary Tuesday or during an urgent outage.

Keep the register somewhere the business controls, such as its own shared drive or password manager. Do not leave the only copy in a project management tool that disappears when the supplier relationship ends.

1. Put ownership in the business name

The domain, hosting account, analytics property and paid licences do not all have to use the same login. They do need a named owner inside the business, with access that survives staff changes and supplier changes.

A common Dubai launch scenario goes like this: the company approves the site, then later finds the domain, premium plugin licences and GA4 property are held under a supplier’s master account. The supplier may be perfectly helpful. That is beside the point. The business should not need permission to renew its own domain or see its own enquiry data.

Ask who owns the billing account, who receives renewal notices and which recovery email is attached to each service. An old employee’s personal Gmail address is not a recovery plan.

2. Check the access that tends to be missed

WordPress administrator access matters, but it is only one key. Check these routes before the project is called complete:

• Domain registrar and DNS provider access, including the ability to change nameservers.
• Hosting control panel, file access and database access where appropriate.
• WordPress administrator access for more than one trusted person.
• Theme, plugin and page-builder licence accounts, especially where updates depend on an annual subscription.
• GA4, Search Console, tag manager and cookie consent platform ownership.
• Form, CRM, booking, payment, newsletter and SMTP accounts.
• Design source files, brand assets and any custom code repository.

SMTP is an especially boring detail until it fails. A form can show a success message, while its email delivery relies on an SMTP account nobody can enter. Test a real submission, check the receiving inbox and spam folder, then note the route in the register.

3. Record what renews, when and how

Renewals are where incomplete handovers tend to surface. List the renewal date, payment method, billing contact and what happens if the item is not renewed. A domain expiring is obviously serious. A form plugin, security service or email delivery subscription expiring can also interrupt work at an awkward time.

Set calendar reminders in a business-owned calendar, not only in the developer’s task list. Finance should know which costs are recurring, while the website lead should know whether a renewal has technical consequences.

4. Make recovery a tested route, not a hopeful one

A backup is useful only if somebody knows where it is, what it contains and how to restore it. The handover should state whether backups sit with the host, a WordPress backup service or both, how long they are retained, and who can request or run a restore.

Include the staging copy if one exists. A staging site is often left behind after launch with an outdated contact form recipient, old tracking code or an exposed login. It should either have a named purpose and owner, or be removed properly.

5. Write down the post-launch boundary

There is usually a short period after launch for genuine build defects, content corrections and snags. That is different from new features, new pages, third-party service changes or a plugin update six months later. Get the boundary written down while everyone still remembers what was agreed.

If ongoing support is needed, name who handles updates, troubleshooting, backups and monitoring after the warranty period. The difference between website design and the technical work behind it should also be clear before approval, particularly where integrations, forms and content responsibilities cross over. Our guide to website design in Dubai helps separate those moving parts earlier in a project.

6. Run a short handover meeting

Do not send a folder of logins and call it training. Schedule a short recorded session covering the tasks the business will genuinely do: edit a page, check an enquiry, find analytics, manage users, request support and locate the backup route.

Ask the business contact to perform at least one task during the session. If they cannot find the form notification settings or identify the domain account without prompting, the handover is not finished yet.

Incomplete handover becomes takeover work later

When access, ownership and documentation are left vague, a later repair begins with proving who controls what. That can delay a simple update while accounts are traced, recovery emails are changed and suppliers are contacted. Our WordPress website repair takeover checklist shows the sort of ownership gaps that tend to reappear once a site needs work after launch.

Questions worth settling before sign-off

What access should a website owner receive at handover?

The business should receive or control access to its domain, DNS, hosting, WordPress administration, analytics, tracking, forms, email delivery, paid licences, backups and source assets. Access does not mean every person needs every password. It means named business contacts can reach each critical account and recover it if a supplier or employee is unavailable.

Who should own the domain, licences and analytics accounts?

They should normally be owned by the business that relies on the website, using business-controlled billing and recovery details. A supplier can be given suitable access to manage technical work. Supplier-owned accounts can be workable where clearly agreed, but the business should understand the dependency, renewal process and exit route before launch.

Do not approve final handover until every critical asset has a named owner and recovery route. If you want a practical second pair of eyes on the register, email Standish Services about your website handover.