Handovers go wrong for structural reasons, not because anyone behaves badly, and the order you do things in matters more than your contract does.
Changing development supplier is a normal business event, and it goes wrong in predictable ways that have very little to do with who was at fault. The single biggest determinant of how badly it goes is not your contract and not your supplier's character. It is the order you do things in.
This article is the process. Two siblings cover the assets: who actually owns your code under UAE copyright law, and the accounts your business must hold.
Two things this article will not do. It will not give you legal advice, and where a question turns on your contract or on UAE law we say so and route you to a lawyer. And it will not tell you that agencies as a class behave badly, because they do not, and the failure modes below are usually structural rather than deliberate.
Secure your access before you give notice
Confirm you hold administrative access to every account before you tell anybody you are leaving. Almost everybody does this in the wrong order.
Before you say anything, confirm you hold administrative access to every account your product depends on. Add yourself where you are missing. Export anything that will not transfer. Then have the conversation.
The reason is not suspicion. It is that the moment notice is given, your project stops being your supplier's future revenue and becomes an administrative task competing with live work for people who are being reassigned. Requests that would have taken an afternoon start taking a fortnight, and nobody involved is doing anything wrong. Goodwill is a resource and it is cheapest to spend before a relationship is formally ending.
The corollary is worth stating too. If you have arranged your accounts as our accounts guide recommends, with your business holding each account and your supplier holding a scoped role inside it, this step is a ten-minute check rather than a negotiation.
What genuinely transfers
More than people fear. Code repositories transfer between owners on the major platforms [2]. Apple and Google both document app transfer between developer accounts, each with conditions and specific exclusions [3][4]. Cloud accounts can generally be brought under your control without rebuilding [5]. Domains transfer subject to registry rules and lock periods, which differ between generic top-level domains and .ae [6][7].
Our accounts guide covers the mechanics and the traps in detail, so this article will not repeat them. The short version is that the technical assets are movable, with conditions worth verifying in advance rather than discovering mid-transition.
What does not transfer, which is the part that actually hurts
Nobody can hand over what is only in somebody's head.
The code can be copied. The accounts can be reassigned. What cannot be transferred is the understanding: why the architecture is shaped the way it is, which parts are fragile and should be touched carefully, what was tried and abandoned two years ago for a good reason, the defect everybody knows about and works around, and the deployment step somebody performs from memory.
That loss does not show up as a crisis. It shows up as six months of a new team moving slowly, breaking things that used to work, and rediscovering constraints the old team knew. It is the real cost of a badly prepared handover and it is almost entirely preventable.
A survivable handover document contains five things:
- An architecture overview. What talks to what, and why, at a level a competent developer who has never seen it can follow
- Environment and deployment instructions that somebody other than the author has followed successfully, start to finish
- A dependency list, including where each third party's credentials live and who holds the account
- Known defects and rough edges, written down honestly rather than curated
- The decisions nobody wrote down, particularly the ones that look wrong until you know the reason
If you ask for one additional thing, ask for a recorded walkthrough. An hour of a departing developer talking through the system, the deployment, and the parts they would warn you about captures more than a document and costs almost nothing. It also preserves the tone of the warnings, which written documentation tends to sand off.
The contract questions, and where we stop
Notice periods, what a supplier must deliver on termination, and whether deliverables can be withheld against an unpaid invoice are all contract and law questions. We are not going to answer them in an article, and we would be wary of any development company that did.
One thing is worth knowing before anyone quotes you provisions, though. UAE contract law changed recently: the Civil Transactions Law that governed for decades has been replaced by Federal Decree-Law No. 25 of 2025, in force since 1 June 2026 [1]. A contract signed before that date may still sit under the previous law, so establishing which regime applies to yours is among the first things to do. We could not load the primary text to verify article-level detail, so we are not citing specific provisions, and we would treat any article that confidently does so with caution unless it is very recent. Take your position to a qualified UAE lawyer.
What you can do without a lawyer is read your own contract before you need it, and note what it says about notice, deliverables on termination, and documentation. Most people first read their development contract during the argument.
Reading the signs, fairly
The symptoms worth acting on are observable rather than emotional:
- You do not have access to your own repository, or you have to ask for it
- Releases cannot happen when one specific person is unavailable
- There is no written record of decisions, so the same discussions recur
- Estimates reset rather than converging as the work becomes better understood
- The same defects keep coming back
Any one of those is a conversation to have with your current supplier, and a good one will engage with it. Several together, sustained over months, is a pattern.
Now the uncomfortable half. Changing requirements without changing the budget, deciding slowly, having no single decision-maker, and treating estimates as commitments all produce those exact symptoms. Moving supplier does not fix a client-side problem. It resets the relationship, adds a learning curve, and reproduces the dynamic with people who do not yet know your business. Before you move, be honest about which parts are yours.
A pattern we see. A business gives notice, then asks for the handover. The outgoing team is now working an unpaid administrative task for a client who has already left, alongside live work for clients who have not. The documentation that arrives is thin, the questions get slower answers, and by the time the new team starts, the people who knew the system have moved on. Nobody behaved badly. The order was wrong.
What a good outgoing supplier actually does
A professional outgoing supplier documents the system without being chased, records a walkthrough, and tells you honestly which parts they were never happy with.
A professional outgoing supplier writes the documentation without being chased, records the walkthrough, answers the incoming team's questions for a couple of weeks after the invoice is settled, and tells you honestly which parts of the system they were never happy with. That last one is the most valuable thing a departing developer can give you and the hardest to ask for, because it involves admitting something.
They also do the unglamorous administrative work: transferring the accounts they hold, confirming in writing what they have transferred, and removing their own access rather than leaving it in place. A supplier who tidies up after themselves is telling you something about how they operated while they were working for you.
If your outgoing supplier does these things, say so publicly. This industry has very little reliable signal about who behaves well at the end of a relationship, precisely because the people best placed to comment have just stopped working together. A specific, factual reference about a clean handover is genuinely useful to the next business making this decision.
And if you are the one being left, the same logic applies commercially. The handover is the last impression you make, it is the thing that gets mentioned when your name comes up, and it costs a few days.
What the incoming supplier should do first
The incoming team should read, run and record for a fortnight before changing anything or estimating anything.
The first useful act is getting the system running in a fresh environment using only the documentation provided, because that immediately reveals everything the documentation is missing. Then establish the dependency tree and whether anything in it is unmaintained. Then get it under proper version control if it is not already. Then write down what was found.
Only after that should anyone estimate work, and a supplier who quotes a fixed price for changes to a system they have not read is either very confident or about to lose money. Expect a review period, and be suspicious of anyone who does not want one.
Rotate credentials as part of the transition, as routine rather than as accusation. Cloud keys, database passwords, third-party API keys, gateway credentials, and signing certificates where possible. This is what any business does when anyone with access leaves, and framing it that way keeps it from reading as distrust.
If you run both suppliers in parallel, keep it short and define who can deploy. A brief overlap where the outgoing team answers questions is valuable. A long overlap where both teams can change the same code produces conflicts and lets each side attribute problems to the other.
Why a takeover is sometimes priced like a rebuild
This is where a lot of buyers conclude they are being ripped off, and often they are not.
Understanding somebody else's system can take longer than writing your own. With a rebuild, a supplier controls the design and can estimate it. With a takeover they inherit decisions they did not make, in code they have not read, with defects nobody catalogued and tests that may not exist. Quoting a fixed price against that is how suppliers lose money, so they either price the uncertainty in or decline the work.
Sometimes the honest conclusion is that replacing the system is cheaper than understanding it. That is a real answer rather than an upsell, and you want a supplier willing to say it in either direction.
What it costs
A codebase takeover review starts from around AED 4,000 with us. That covers getting the system running from whatever documentation exists, mapping the dependencies, identifying what is missing, and giving you a straight view on whether to continue with it or replace it. These are our own figures rather than a market survey, since no official body publishes rates for this work. Final pricing depends on the size of the system.
Part of that review you can do yourself before paying anyone, and it is worth doing. Does the system run from the documentation on a machine that has never run it? Do the tests pass, and are there tests? When were the dependencies last updated? Three answers, no specialist knowledge required, and they tell you most of what you need to know about what you are holding.
What this costs you in time, not money
A handover costs a few hours of senior attention, days of chasing your outgoing supplier, and a month of reduced throughput from the incoming one. The schedule is where businesses get caught, not the budget.
Expect the inventory and access work to take a few hours of somebody senior's attention, not a project. Expect the documentation request to take your outgoing supplier days rather than hours, and to need chasing. Expect the incoming team to be slower than their estimate for the first month, because they are reading rather than writing. And expect your own throughput to drop during the overlap, because you will be answering the same questions twice.
The determining factor in all of it is documentation quality rather than codebase size. A small, undocumented system takes longer to hand over than a large, well-documented one, which is counterintuitive until you have done both. If you want a shorter handover next time, the lever is insisting on documentation during the build rather than requesting it at the end.
One practical scheduling point: do not start a supplier change in the same month as a launch, a busy trading period, or an audit. The handover will lose every contest for attention, and a half-completed handover is the worst of the available outcomes because both teams believe the other one has it.
The sequence, in order
- Read your contract, particularly notice, deliverables on termination, and documentation
- Confirm and secure administrative access on every account, adding yourself where missing
- Export what will not transfer, including analytics history and reporting
- Request the handover document set and a recorded walkthrough, while relations are good
- Agree explicitly what happens to work in progress
- Give notice
- Start the domain transfer immediately, because it has the longest lead time
- Rotate every credential the outgoing team held
- Give the incoming team a read-and-run fortnight before asking for estimates
- Put a handover clause and a proper IP assignment in the next contract
If you are weighing whether to move, or you have inherited something and want an honest view of what you are holding, contact us. We will tell you if the answer is to stay where you are.
If you are the supplier reading this
The commercial case for a clean handover is stronger than it looks, and this section is addressed to suppliers rather than buyers.
The commercial case for a clean handover is stronger than it looks. You will be mentioned when your former client is asked for a recommendation, and what gets mentioned is almost never the quality of the code. It is whether you made leaving difficult. A few days of documentation buys a reference that outlasts the account, and the alternative buys a story that also outlasts it.
There is a second-order effect. A supplier known for clean exits gets asked to take over other people's work, which is often better business than competing for greenfield builds on price.
References
[1] UAE Federal Decree-Law No. 25 of 2025 on Civil Transactions, in force 1 June 2026. uaelegislation.gov.ae
[2] GitHub Docs, Transferring a repository. docs.github.com
[3] Apple, Transferring apps, App Store Connect Help. developer.apple.com
[4] Google Play Console Help, Transfer apps to another developer account. support.google.com
[5] Amazon Web Services, Managing an AWS account. docs.aws.amazon.com
[6] ICANN, Transfer Policy. icann.org
[7] TDRA and .aeDA, .ae Domain Name Policy. tdra.gov.ae
