A UAE business decides to change web developer and discovers three things in the same afternoon. The domain is registered to the previous agency. The app is published under a personal Apple account belonging to a contractor who left. And the person who set up Search Console two years ago can still, quietly, reclaim ownership of it.
None of that is unusual. It is what happens when access is arranged for convenience during a build and nobody revisits it. This article works through each asset, using what the platforms themselves publish, and pays particular attention to the cases where a transfer is conditional or impossible rather than routine.
Two siblings cover the rest of the ownership question: who actually owns your code under UAE copyright law, and how to change development agency without losing your product.
The arrangement you actually want
Your business owns the account. Your supplier holds a scoped role inside it.
That single pattern resolves most of what follows. It works cleanly on developer accounts, cloud, repositories and the Google tools. It works less cleanly on domains, where the registrant question is binary rather than a permission. It generally does not work on merchant accounts, which in practice have to be yours.
The reason it matters is asymmetry. Access granted to you can be withdrawn. An account you hold cannot. If the supplier owns it and gives you a login, your position rests on their goodwill and their continued existence as a company. If you own it and give them a role, you can remove them in a minute and nothing else changes.
Domains, where the distinction is registrant versus contact
The registrant is the party a domain is registered to. The administrative contact is a nominated contact for administrative matters. Those are different roles and they get conflated constantly, including by suppliers acting in good faith [2].
The distinction becomes decisive at transfer time, because authority over the registration is what matters. A transfer requires an authorisation code from the current registrar, and obtaining it depends on holding that authority [1]. If your agency is the registrant rather than a contact, the domain is registered to them.
Waiting periods catch people mid-migration. ICANN's policy sets out separate 60-day periods around initial registration, a prior transfer, and a change of registrant, of which the change-of-registrant lock is the mandatory one [1]. Plan accordingly, and check the current policy directly, because ICANN revises it and we would rather you read it than trust our summary.
On .ae, do not assume any of the above applies. The ICANN policy governs generic top-level domains through accredited registrars. We found no confirmation that the .ae registry has adopted the same transfer policy, and the .ae policy document we could read is dated 2010 and contains no equivalent lock provisions [3]. It does contain two things worth knowing: it describes a registration as an exclusive licence to use rather than as ownership, and it sets eligibility conditions including a UAE trade licence requirement for the co.ae and net.ae namespaces [3]. Confirm the current position with the regulator.
One more honest note. There are dispute mechanisms for abusive registrations involving bad faith or trademark infringement. We could not confirm they apply to a supplier who registered a domain in good faith while working for you, which is the scenario this article is actually about. Do not plan on a formal remedy being available.
Developer accounts, where transfer has hard blockers
Apple documents an app transfer process, and the app has to meet eligibility criteria [4]. Two of those blockers are permanent rather than fixable: an app sandboxed on macOS that shares an application group container with another app, and an Apple Arcade app [4].
That is the kind of detail worth checking before you rely on a transfer as your exit plan. What Apple describes as an alternative for a permanently ineligible app, we could not establish, so we are not going to tell you that republishing from scratch is the answer.
Also worth knowing: a transfer is not lossless. Apple's documentation sets out what moves and what does not, and promotional codes and the full analytics history stay behind [4]. Export what you want to keep before you move.
On Google Play, more than one mechanism exists and which applies depends on your case. The simpler ownership-transfer route carries exclusions, and a monetising personal developer account is among them [5]. That is a specific trap for a business whose app was published under an individual's account and has since started earning.
All of which is an argument for the thing our app store rejection guide already recommends from the submission side: register the account as your organisation at the start. Doing it then costs a form. Doing it later costs a process with conditions you may not meet.
Cloud and code
On cloud, the goal is that the account is yours with your supplier holding scoped access inside it. AWS documents how root account contact details and the payment method are managed [6], which means an account can generally be brought under your control without rebuilding anything.
What you should not accept is your production infrastructure living inside a supplier's account alongside their other clients. That makes your uptime dependent on their billing relationship and your data dependent on their internal access controls.
On whether individual resources can move between accounts, some can and some cannot, and we could not find a consolidated published list. So we are not going to give you one. Ask your supplier which of your resources are account-bound, in writing, before planning anything.
On code, hold repositories in a company organisation rather than an individual's personal account. GitHub documents repository transfer and the difference between the two [7][8], and an organisation is the structure that survives a person leaving.
One detail that catches people: configuration such as webhooks and secrets generally moves with a repository, while sites published through GitHub Pages do not [7]. If your documentation or marketing site is being served from a repository you are about to move, find out first.
The Google tools, where there is no transfer at all
Analytics, Tag Manager and Search Console do not have an ownership-transfer mechanism in the way a domain or repository does. What exists is role and permission management [9][10][11]. So the objective is not to receive these handed over. It is to hold administrative access yourself.
The Search Console detail is the one to take away from this article. Ownership rests on a verification method, and removing someone as an owner does not necessarily end their ability to return. A removed owner whose verification token is still present on your site or in your DNS can re-verify and reclaim ownership [11]. The complete action is to remove the person and remove their verification token. When a supplier relationship ends, go looking for stray verification files and DNS records.
Tag Manager has the mirror-image risk. Google's own documentation warns about removing the last user with administrative rights and losing the ability to manage the container [10]. The safe sequence is always add yourself first, then remove them.
A pattern we see. A business tidies up after a supplier leaves, removes their user accounts everywhere, and feels organised. Six months later a tag nobody recognises appears on the site, or an old owner's name shows up in Search Console again. Nothing malicious happened. The permissions were removed and the underlying verification was not.
Merchant accounts, which cannot simply be handed over
This is the one asset in this article that usually has to be established fresh in your name.
Providers operating in the UAE tie a merchant account to a named legal entity through onboarding and know-your-customer checks, and the Central Bank regulates retail payment services [12][13][14][15]. We did not find a provider page stating in terms that accounts are non-transferable, so treat that as the practical consequence of the identity requirements rather than a quoted rule, and ask your provider directly about your case.
The reason to treat it as urgent rather than administrative is that this is where your money arrives. Payments for your business flowing through somebody else's merchant account is a commercial and regulatory exposure, not a convenience. The account should be in the name of the entity holding the trade licence and the bank account.
Email, the asset nobody puts on the list
Your business email almost always depends on the domain, and that dependency is invisible until the domain is at risk.
If your domain is registered to somebody else, they can change the DNS records that route your mail. That is not a hypothetical inconvenience, it is your invoices, your client conversations, your password reset links and your account recovery for everything else in this article. Losing mail routing is worse than losing a website, because a website going down is visible and mail quietly not arriving is not.
Two practical consequences follow. First, the domain sits at the top of the priority list precisely because email hangs off it, not just because the website does. Second, when you audit access, check who can edit DNS as a separate question from who holds the registration, because those are often different people and both matter.
There is a related point about recovery addresses. Many platform accounts recover through an email address, so a recovery address on a domain you do not control, or on a departed employee's mailbox, undermines the ownership you have carefully arranged everywhere else. Point recovery addresses at a mailbox the business controls and more than one person can reach.
The sequence that protects you
Secure access first, then remove verification tokens, then give notice. The order matters more than the effort.
- Secure access before giving notice, not after
- Confirm you hold administrative rights on every account, and add yourself where you do not
- On Search Console, remove verification tokens as well as users
- On Tag Manager, add yourself before removing anyone
- Export what will not transfer: analytics history, promotional codes, anything reporting-related
- Only then have the conversation
This is not about expecting bad behaviour. It is that access questions are dramatically easier to resolve while everyone is cooperating and nobody is counting down a notice period. Our changing agency guide covers the rest of that sequence.
If your supplier is offshore, all of this matters more rather than less. Enforcing anything across a jurisdiction is slow and expensive, which means the practical remedies carry more weight than the legal ones. Owning the accounts yourself is jurisdiction-independent.
Setting a new supplier up correctly, which takes ten minutes
Create every account yourself before work starts and invite the supplier in. That single habit removes every problem above, and it belongs in your onboarding rather than your contract.
Before any work starts, create the accounts yourself: the domain in your company's name, the developer accounts as your organisation, the cloud account under your billing, the repository in a company organisation, and the analytics properties under an administrator who works for you. Then invite the supplier into each one with the access they need.
Name a second person internally on every account. One person holding all the administrative access is the same single point of failure as a supplier holding it, and it fails in a more awkward way, because that person may be on leave or may have left. Two people, both employees, on every account.
Keep the inventory somewhere shared. A list of accounts, who holds them, and which supplier has access, in a document more than one person can reach. Not in an inbox and not in one person's password manager.
Point recovery addresses at a shared mailbox rather than an individual, for the reason set out above.
Ask the transfer question during procurement, not at the end. What happens to each account if we stop working together is a fair question to put to a supplier before you sign, and the answer tells you a great deal about how they operate. A supplier who has thought about it will have a straightforward answer. That in itself is a useful signal.
None of this requires trust or its absence. It is the same reason a business keeps its own accounting records rather than relying on its accountant's copy.
What it costs
An access and ownership audit starts from around AED 1,500 with us. That covers an inventory of every account your product depends on, who currently holds it, what is missing, and the order to fix things in. These are our own figures rather than a market survey, since no official body publishes rates for this work. It combines naturally with the code and licence audit in our code ownership guide.
There is no published figure for recovering a stranded account, and we looked. No platform, registry or government body publishes one, because the cost depends entirely on whether the current holder cooperates. That asymmetry is the whole argument for doing the preventative version: it has a price, and the recovery version does not have a ceiling you can plan around.
The annual review worth doing
Walk the full list once a year and whenever a supplier relationship changes, because accounts drift: somebody adds a tool, a contractor sets up a service under their own login, a renewal moves to a different card. Once a year, and whenever a supplier relationship changes, walk the list: domain, DNS, developer accounts, cloud, repositories, analytics, tag manager, search console, merchant account, and every third-party service that sends you an invoice.
If you fix only two things, fix the domain and the merchant account. The domain because everything points at it, including your email, and losing it takes you offline in a way nothing else does. The merchant account because it is where revenue lands and because it is the one asset that generally cannot be transferred at all.
If you would like the inventory done properly rather than from memory, contact us.
References
[1] ICANN, Transfer Policy. icann.org
[2] ICANN, Registrant rights and responsibilities. icann.org
[3] TDRA and .aeDA, .ae Domain Name Policy. tdra.gov.ae
[4] Apple, Transferring apps, App Store Connect Help. developer.apple.com
[5] Google Play Console Help, Transfer apps to another developer account. support.google.com
[6] Amazon Web Services, Managing an AWS account. docs.aws.amazon.com
[7] GitHub Docs, Transferring a repository. docs.github.com
[8] GitHub Docs, Organization ownership and roles. docs.github.com
[9] Google Analytics Help, Manage account and property access. support.google.com
[10] Google Tag Manager Help, User permissions. support.google.com
[11] Google Search Console Help, Managing owners, users and permissions. support.google.com
[12] Telr, merchant onboarding requirements. telr.com
[13] PayTabs, merchant account requirements. paytabs.com
[14] Stripe, United Arab Emirates account requirements. stripe.com
[15] Central Bank of the UAE, Retail Payment Services and Card Schemes Regulation. centralbank.ae
