Who owns your website after handover? A website handover checklist for UAE companies

What does a website handover in the UAE actually hand over?

Most website handover checklists for UAE companies list deliverables: pages, a style guide, a training call, a zip file. Those matter less than one question that rarely appears on them. When the project ends, whose name is on each account the website depends on? A site in Dubai can look finished and still belong, in every way that counts, to the people who built it.

Handover is the wrong picture anyway. It suggests that something passes from the builder to you on the last day. Ownership should sit with you from the first day, whoever builds the site and whoever keeps it running later. The pillar on domain, email and website for a new UAE company covers what to set up after the trade licence. This piece is the check that it ended up in the right hands.

Here is what that looks like in practice. A trading company in Sharjah wants to change its menu text a year after launch. The developer has moved on. The domain renews on a card nobody recognises, and the hosting login sits in a mailbox of someone who has since left the company. Nothing is broken. Nothing can be changed either.

Whose name is on the domain?

The domain is the one item you cannot rebuild. Everything else, from the email to the website, hangs off it. ICANN's transfer policy is explicit about who decides: "The Administrative Contact and the Registered Name Holder" are "the only parties that have the authority to approve or deny a transfer request", and where the two disagree, the holder wins (ICANN Transfer Policy). If an agency registered the name under its own company, it holds that authority, not you.

The same policy says registrars must give the registered name holder the transfer code, the "AuthInfo" code, and if they offer no tool for it, within five calendar days of the holder's request (ICANN Transfer Policy). That right is only useful if the holder is you. ICANN also puts the duty on the registrant to keep contact details accurate and to "promptly update this to reflect any changes" (ICANN, registrant benefits and responsibilities). A domain registered to a freelancer's Gmail address fails that test the day the freelancer stops answering.

Say a clinic in Dubai bought its .ae name through the web agency that built the site. National .ae names are sold through registrars that the TDRA accredits (TDRA, aeDA), and an agency may buy through its own account with one of them. Ask for the registrant record, not a screenshot of the website. The record should show the clinic's legal name and an email address the clinic controls.

Who can log in as administrator?

The second item is the administrator account of the site itself. For WordPress the official documentation defines the Administrator as "somebody who has access to all the administration features within a single site" (WordPress, roles and capabilities). That is the level your company needs to hold, with a login tied to a company address and not to a person.

This is not about distrust. The builder keeps their own login and works as before. What changes is that you no longer need their permission to add a colleague, remove a former employee or bring in someone else. Hosting works the same way. The hosting contract should be in your company's name and paid by your company, with the builder invited as a user, not the other way round.

Take a free zone company in Abu Dhabi whose site runs on a hosting plan inside the agency's account. When the agency changes its own hosting provider, every client site moves with it, on the agency's timetable. That is fine as long as the relationship is good. A checklist is for the day it is not.

Who owns the analytics and Search Console?

Measurement is where ownership slips most quietly, because the setup is quick and whoever does it becomes the owner. Google Analytics only lets users with the Administrator role add or change users, and "if you are the last user who has the Administrator role, you cannot delete yourself" (Google Analytics help, access management). If that last administrator is your former agency, your history of visits sits in their hands.

Search Console separates verified owners, who proved ownership with a token on the site, from delegated owners and users. If all verified owners are removed, "all remaining users and delegated owners will lose access to the property after a grace period" (Search Console help, owners and users). The same page warns that a removed owner whose token stays on the site can verify again. For example, when an agency leaves, removing it from the user list is not enough: its verification token has to go too, and your own verification has to be in place first.

What if your analytics runs on self-hosted Matomo?

Not every UAE site measures with Google. We run self-hosted Matomo for our own site and for the sites we look after, so visit data stays on our server and does not go to an outside analytics provider. That settles one ownership question and opens another. No third party holds the data, but the server still is not yours. On a shared installation the useful test changes: not who the administrator is, but what you can take out without asking anyone.

Matomo ties roles to a single website, and only the Superuser can act on every site and on the system settings (Matomo, user roles). A client on a shared installation gets a website role, and for day-to-day export that is enough. Matomo's own guidance for pulling visit-level data is a user with view permission on the site, calling the Live.getLastVisitsDetails method with that user's token, with the output in JSON, XML or CSV (Matomo, raw data export).

Say a Dubai clinic wants its March visits in a spreadsheet. With a login limited to its own site, it requests that month as CSV and has the file the same day, with no ticket to anyone. Two limits are worth asking about before you rely on that. The first is retention. Matomo recommends deleting older raw data once the reports have been generated, and reports can be kept separately (Matomo, raw data and report data). If raw visits are kept for 180 days and you export once a year, half of that year survives only as reports. Ask what the period is, and export inside it.

The second limit is the exit. Matomo says no database query exists that exports the data of one site alone (Matomo, moving data between installations), and its Migration plugin, which copies one website with raw data and reports to another installation, runs on the command line of the source server (Matomo, Migration plugin). You cannot do that from a website login. This is the one line on the checklist where the account cannot sit in your name, so get it in writing: a full copy of your site's analytics data when the arrangement ends, and who carries it out.

What should a website handover checklist contain?

The useful version is short. For each line, write down the account, the name it is registered to and who else has access:

• Domain: registrant is your company, contact email is a company address, renewal is on a company payment method.
• DNS: you hold a login to wherever the records are managed, which is not always the registrar.
• Hosting: contract and invoices in your company's name, builder added as a user.
• Website: at least one administrator login on a company address, and a current export of the site files and database that you keep yourself.
• Business email: the admin account of the mail provider sits with your company, as set out in the guide to business email for a new UAE company.
• Analytics and Search Console: your company is an administrator and a verified owner. On a shared Matomo: your own login for your site, one export you have actually run, and a written right to a full copy when the arrangement ends.
• Third-party services: forms, maps and fonts that use API keys or subscriptions, each listed with the account that pays for it.

A technical check of the website tells you what is running. This list tells you who can change it.

Does owning everything mean the builder walks away?

No, and this is the part most checklists get backwards. They treat handover as an exit: the builder hands over keys and leaves, and website maintenance becomes someone else's problem. The better arrangement is the opposite. You own every account from the start, and the person who built the site keeps running it, inside your accounts, for as long as you both want that.

Picture what changes if you later decide to end the arrangement. Nothing moves. No transfer code, no migration, no hunt for passwords. You remove one user and add another. That is the real test of a website maintenance arrangement in Dubai or anywhere else: whether it can end without anything breaking.

How the site, the enquiry path and the ongoing work are set up together, with the accounts in the client's name and analytics data the client can take out, is described on our services page.