Software escrow gets recommended a great deal and examined almost never. It sounds like insurance, it is priced like insurance, and the assumption is that having it means you are covered.
What the standard agreement actually buys is custody of a file. Whether that file is useful is a separate product, sold separately, that most buyers never purchase.
This article is about that gap.
First, three different things called escrow
Worth clearing up immediately, because the word does three unrelated jobs.
Payment or milestone escrow holds a client's money and releases it to a supplier when a contract milestone is met, or holds a marketplace buyer's payment until delivery is confirmed. A financial mechanism, nothing to do with code.
Real estate escrow in Dubai is a government-regulated regime under Dubai Law No. 8 of 2007, requiring off-plan developers to deposit buyer payments into project-specific accounts with approved trustee banks, released in stages against construction progress [7].
Source code escrow is the subject here: a neutral third party holds a copy of software and releases it on a defined trigger.
If you have seen escrow mentioned elsewhere in the context of a development project, check which one was meant. They are not interchangeable and the protections are entirely different.
The mechanics
A software escrow agreement is a three-party contract between the supplier who deposits, the customer who benefits, and a neutral agent who holds [1]. The agent stores a copy of the source code and related materials and releases them to the customer only if a trigger occurs.
Common triggers named by providers include bankruptcy, failure to maintain the software, breach of contract, and termination of support, with the exact conditions written into each individual agreement rather than being standard [1].
One detail buyers routinely miss: the deposit is not a one-time event. Providers advise refreshing it on a set frequency, monthly, semi-annually or annually [5]. An escrow arrangement without an update schedule holds a snapshot that drifts further from your live system every week, and the day you need it is precisely the day that drift becomes the entire problem.
What escrow does not do
The deposit gives you a copy of files. On its own, it does not give you:
Somebody who understands the code. This is the same limitation a handover has, and we have written about it before: nobody can hand over what only exists in somebody's head.
The environment the software runs in, meaning cloud configuration, infrastructure definitions, and secrets.
The third-party credentials it depends on. API keys, payment gateway access, DNS control. Those live in accounts, and if the accounts are not yours, the code alone will not run. Our guide on the accounts your business must own covers that separately and it matters more than escrow does.
The deployment process, meaning how a build actually reaches production.
The right to use every licensed component inside it. Open source and commercial third-party licence terms are a distinct legal question from possessing the files, covered in our guide on who owns your code.
Verification is the whole argument
Here is the part that decides whether an escrow arrangement is protection or decoration.
The verification included free with a standard agreement checks that files are readable, that nothing is locked behind an unknown password, and that the deposit passes a virus scan [2]. It makes no attempt to compile anything, run anything, or check the deposit against your production system.
Everything that does test usefulness is a separately priced purchase. One provider publishes five paid tiers above the free check: a file listing with hashes at around 295 US dollars, an engineer's review of documentation and dependencies without a build at around 1,095, an actual build with tests run from around 2,995, a comparison of the built executable against your production one, and a full test plan for interpreted-language projects at a custom quote [2]. Another provider publishes four tiers, ranging from a build inside the vendor's own environment through to an independent rebuild of the full production environment by the escrow agent [4].
The pattern across both is identical. There is a very large gap between "we confirmed the file is not corrupted" and "we independently rebuilt your production environment from this deposit and it runs", and nothing in the base agreement closes it.
Which means an escrow agreement can be signed, paid for, and renewed annually for a decade, while nobody has ever confirmed the deposit compiles.
We are not going to tell you how often that happens, because the figures in circulation come from providers selling verification upgrades. We do not need a statistic. The pricing structure tells you everything: assurance is optional, and optional things do not get bought.
What it costs
All published pricing is in US dollars. No provider we found publishes a dirham rate, so treat any AED figure as a conversion rather than a local market price.
One provider lists a setup fee of around 995 dollars with annual fees running from roughly 1,390 to 2,495 depending on the beneficiary arrangement, plus around 250 for each release and additional fees per extra product or beneficiary [3]. Another prices setup at around 249 with a single agreement at roughly 1,668 a year billed annually, and a multi-agreement plan at around 3,108 [6].
Add a genuine build verification and you are adding roughly 3,000 dollars again, on top, per verification.
So the honest summary is this: the headline annual fee buys custody, and proof costs about the same again, and only if you ask for it.
What should be in the deposit
Providers publish their own lists, and they are worth reading, because they double as a specification for something else.
The materials named include source code in native format, design documentation covering architecture and module interactions, build instructions, the build environment and compiler configuration, a roadmap of the deposit so components can be located, any required passwords, a description of the software, the component dependency list, build control files, third-party application details with version numbers and vendor contacts, interface documentation, test diagnostics including regression tests, contact details for key programmers, and details of required patches [5].
Now compare that against what our own guide on code ownership says a proper delivery should contain: repository access with its history rather than an export, build and deployment instructions, environment configuration, a map of where third-party credentials live, a dependency list with the licence attached to each component, and documentation of the decisions a newcomer would otherwise have to reverse-engineer.
They are almost the same list.
That is the finding worth taking away from this article. An escrow deposit built to a proper standard is functionally the same artefact as a proper delivery. Most of what escrow is being bought to guarantee is obtainable directly, at any time, by insisting your supplier hand over a delivery that meets that bar. No third party, no annual fee, and no trigger event to prove.
The alternatives
Hold the repository yourself, with the supplier working inside it. You get a live, current copy at all times rather than a sealed archive, at zero incremental cost, with no waiting for a release. The weakness is that it depends on you actually enforcing regular commits rather than accepting one large drop at the end, and it does not by itself capture environment configuration or third-party credentials unless those accounts are also in your name.
A contractual right to the code plus a proper handover clause. Costs nothing beyond negotiation and produces the same package. Our guide on changing your development agency sets out what a handover document should contain and how to write it into an agreement before you need it.
Regular verified deliveries rather than a sealed archive. You receive working code on a cadence and confirm it runs, instead of paying annually for something that gets opened, if ever, only after things have already gone wrong.
The four things that all have to work
Escrow is often described as if it were a switch. Something goes wrong, the switch flips, you get your code. In practice a release depends on four separate conditions, and any one of them failing produces the same outcome as having no escrow at all.
The trigger has to be provable. Insolvency is relatively clean. Failure to maintain the software, or breach of contract, is not. Those are the triggers most likely to matter in practice and the hardest to establish to a third party's satisfaction while the supplier is disputing it, which they will be.
The agent has to release. That is a contractual obligation on a company that may sit in another jurisdiction, operating under law you did not choose, at a moment when the depositor is objecting.
The deposit has to be current. If the refresh schedule slipped, and nobody was checking that it had not, you receive a version of your software from whenever the last deposit actually happened rather than from last month.
Somebody has to be able to build it. Which brings you back to verification, and to whether anybody has ever confirmed that this particular deposit compiles.
Holding the repository yourself removes all four conditions. That is the honest comparison, and it is why we would generally rather see a client spend the equivalent of an escrow fee on enforcing a proper delivery standard than on custody of an archive nobody has opened.
When escrow does earn its fee
Four cases, and they are real.
You depend materially on one supplier for something business-critical and have no practical way to hold a live copy yourself, typically because the product is licensed rather than commissioned.
A counterparty requires it as a condition of the deal. This is a recognised procurement pattern, and providers sell into it directly, including through public-sector procurement frameworks. If a customer requires escrow to close a contract, the commercial question answers itself and the useful question becomes which verification tier they will accept.
You are licensing a closed product where the vendor will not and reasonably should not grant every customer repository access, because doing so would expose the product and possibly other customers' configurations. That is a legitimate refusal, and escrow is the only mechanism that gets you any fallback at all.
You need to evidence a specific control to an auditor. One provider's own material links escrow to a control on management of outsourced development and to business continuity standards, while stating plainly that the standard does not mandate escrow and treats it as one way of evidencing the control objective. That characterisation is the provider's summary of a paywalled standard rather than verified standard text, so check the position with your own auditor rather than with a vendor.
In all four cases, what makes escrow worth the money is the same thing: verification. An unverified deposit under any of these fails the same way it fails anywhere else, except at a worse moment, because these are exactly the situations where you had no other fallback.
The UAE question we cannot answer
Escrow as a concept is thoroughly familiar here, and government-regulated, for real estate funds [7]. There is no equivalent statute or regulator for source code escrow. Where it happens in the UAE it is a private commercial contract, usually with a foreign escrow agent, rather than a licensed activity.
Whether a UAE court would enforce a release is a live question we could not settle from any primary source. We found nothing addressing how an escrow trigger interacts procedurally with a bankruptcy or restructuring proceeding, whether an appointed trustee could disclaim or delay a beneficiary's right to a release, or how a foreign agent's obligations would be treated.
What we can state is the framework. UAE company insolvency is governed by Federal Decree-Law No. 51 of 2023, in force since May 2024, and it does not apply to certain government-owned entities, to free zone companies with their own insolvency regimes including DIFC and ADGM, or to Central Bank licensed institutions [8]. Separately, Federal Decree-Law No. 25 of 2025 promulgates a new civil transactions law replacing the previous one with effect from 1 June 2026 [9], so an agreement signed before that date may sit under the previous regime and one signed after under the new.
Which regime governs your agreement, and what a release would actually look like in practice, is a threshold question for a qualified UAE lawyer on your specific contract. It is not something a provider's marketing page can settle, and it is not something we will pretend to settle either.
We also could not establish how commonly software escrow is actually used by UAE technology businesses. Even a provider actively marketing into this region makes no substantiated enforceability claim on its own page, which is itself worth noticing.
What to do
Ask your supplier for repository access first, and watch what happens. If they agree, you have solved most of the problem for nothing, and the escrow question shrinks to whether a counterparty is demanding it. If they refuse and explain why in terms that make sense, you now know which of the four legitimate cases you are in.
If you do proceed, ask five questions before signing. What exactly does the included verification test, and does it attempt a build. How often is the deposit refreshed and who confirms it happened. What does a release cost and how long does it take. What happens if the deposit fails to build after release. And which jurisdiction the agent operates from.
The single most important one is whether anybody has ever built the deposit. If the answer is no, you are paying annually for custody of files whose usefulness has never been tested.
We can review the technical side of an agreement, meaning what the deposit contains, whether the verification tier is meaningful, and whether the refresh schedule matches your release cadence. That starts from around AED 1,500. A full review of a codebase and its dependencies starts from around AED 4,000. Final pricing depends on scope, and these are our own figures rather than a market survey. The legal enforceability question needs a UAE lawyer rather than us.
References
- EscrowTech International, software escrows
- EscrowTech International, technical verification
- EscrowTech International, software escrow fees
- Escode, testing and verification
- Escode, what is in your software escrow deposit
- Codekeeper, software escrow pricing
- Dubai Land Department, Law No. 8 of 2007
- UAE Government, law on bankruptcy
- UAE Legislation portal
- SKIMBOX, who owns your code in the UAE
- SKIMBOX, the accounts your business must own
- SKIMBOX, changing your development agency in the UAE
Provider pricing accurate as of 23 August 2026 and published in US dollars. This article is not legal advice. Enforceability of an escrow release under UAE law requires a qualified lawyer's opinion on your specific agreement.
