Source Code Escrow Agreements in New Zealand: What Tech Businesses Should Include

If your software is business critical, a verbal promise that the developer will “always support it” is not enough. New Zealand tech businesses often get caught in three places: they sign escrow terms without checking when the code can actually be released, they assume a deposit of source code is useful even though it is incomplete or out of date, and they forget that ownership, licensing and support obligations are separate issues. That can leave a customer unable to run a platform they rely on, or a software provider exposed to a release of valuable intellectual property on terms they never properly tested.

A source code escrow agreement is meant to reduce that risk, but only if the release triggers, deposit requirements and verification process are carefully drafted. The practical questions matter most before you sign a contract, before you accept the provider's standard terms, and before you rely on a verbal promise about access if something goes wrong. This guide explains what a source code escrow agreement means in New Zealand, what clauses deserve close attention, and the mistakes founders and SMEs make most often.

Overview

A source code escrow agreement is a contract under which source code and related materials are held by an independent escrow agent and released only if agreed events occur. It is commonly used where a customer depends on software supplied by a third party and wants a fallback if the supplier stops supporting the product, becomes insolvent, or seriously breaches the agreement.

• Check who owns the source code and whether the supplier has the right to place it into escrow.
• Define exactly what must be deposited, including source code, build instructions, keys, libraries, documentation and deployment materials.
• Make sure the release events are specific, practical and not left to argument.
• Set out how often deposits must be updated and whether the escrow agent verifies usability.
• Align the escrow terms with the main software licence, support agreement, SaaS terms or development contract.
• Limit what the customer can do with the released materials after release, while still allowing business continuity.

What Source Code Escrow Agreement Means For New Zealand Businesses

A source code escrow agreement gives a software customer a practical backup plan, but it does not automatically transfer ownership of the software or create broad rights to use it however they want.

In plain English, escrow sits between two commercial concerns. The customer wants continuity if a software provider disappears or stops performing. The provider wants to protect its intellectual property and only allow release in limited situations. The escrow agreement is where those interests are balanced.

When escrow is usually worth considering

Escrow is most useful where the software is not easily replaceable and the customer would face serious disruption without ongoing access. That often applies to:

• custom-built operational software
• industry-specific platforms integrated into internal systems
• software supporting regulated processes or large customer databases
• legacy software still central to the business
• software supplied by a small vendor where key person risk is high

For many off-the-shelf tools, escrow may not be commercially worthwhile. If the product is easy to replace, or the customer already has broad access and self-hosting rights, the added cost and complexity may not make sense.

Escrow is different from ownership and licensing

This is where businesses often get caught. A source code escrow agreement is not the same as an IP assignment, a perpetual software licence or a maintenance contract.

The owner of the code usually remains the owner. The customer only gets access if a release event occurs, and even then the customer's rights should be limited to what is needed to keep the software working for its own internal business purposes, unless the parties clearly agree otherwise.

Before you sign, make sure the main contract and the escrow deed say the same thing about:

• who owns newly developed code, modifications and derivative works
• whether the customer gets a licence before release, after release, or both
• whether the customer can engage a replacement developer to maintain the software
• whether affiliates, contractors or hosting providers can access the released materials

New Zealand contract context

In New Zealand, escrow terms are generally governed by ordinary contract principles. That means the wording matters. If release events are vague, or if the deposited materials are described loosely, the commercial protection may be much weaker than either side expected.

There may also be related issues under other agreements. For example, if the software processes personal information, release of code and system credentials may trigger privacy and security concerns under the Privacy Act 2020 and broader data protection obligations. If marketing statements promised a level of continuity or support that the contracts do not actually deliver, there can also be Fair Trading Act risk.

For software customers buying services for business use, parties often contract out of parts of the Consumer Guarantees Act where the legal requirements are met. That makes the written contract even more important, because you may not be able to fall back on the same protections that apply in consumer situations.

Three-party and two-party structures

Most escrow arrangements involve three parties: the supplier, the customer and the escrow agent. The escrow agent stores the materials and manages release requests under the agreed process.

Some businesses also use tailored two-party arrangements where code is stored in a controlled repository with contractual release rights. That can be cheaper, but it usually gives less independence and can create arguments about whether the materials were actually complete, current and properly held.

For a business relying on mission critical software, an independent escrow provider is often easier to enforce and easier to explain to investors, lenders or procurement teams.

Legal Issues To Check Before You Sign

The main legal risk is assuming escrow protection exists when the contract does not actually make release, access and ongoing use workable.

1. Who owns the code and who can deposit it?

Before you sign a contract, confirm the supplier really has the legal right to place the code in escrow. If contractors, former developers or related companies contributed to the codebase without proper IP assignments, the supplier may not have clean title.

Ask for the contract to address:

• ownership of the base code
• ownership of customisations funded by the customer
• open source components and their licence terms
• third-party modules or APIs that cannot legally be transferred or sublicensed
• warranties from the supplier that it has authority to deposit the materials

If the customer is paying for custom development, the escrow agreement should also align with the software development agreement. Otherwise, one document may suggest customer ownership while another assumes supplier ownership.

2. What exactly must be deposited?

A promise to deposit “the source code” is rarely enough. A customer cannot maintain software from code alone if key technical ingredients are missing.

The deposit should clearly describe the materials, such as:

• human-readable source code for the relevant software version
• configuration files and scripts
• database schemas
• build and compilation instructions
• deployment procedures
• administrator manuals and technical documentation
• encryption keys, credentials or access procedures where appropriate
• details of required development environments, libraries and dependencies
• test suites or validation materials if needed to prove the software works

Some of those items are sensitive and should be handled carefully. The agreement can require secure storage methods, controlled access and specific release conditions for credentials or keys.

3. When can the code be released?

Release triggers are the heart of a source code escrow agreement. If they are too narrow, the customer may never get access when it genuinely needs it. If they are too broad, the supplier may face an unfair loss of control over valuable IP.

Typical release events include:

• supplier insolvency or liquidation
• the supplier ceasing business operations
• a material breach of support or maintenance obligations that is not remedied in time
• failure to meet agreed service continuity obligations
• the supplier's refusal or inability to maintain the software
• the occurrence of a key person event, if the business depends on one developer and no replacement support is arranged

The drafting should say how a release request is made, what evidence must be provided, how long the supplier has to object, and who decides a dispute. Without a clear procedure, a release event can turn into a practical dead end.

4. How often are deposits updated?

An escrow arrangement is only as good as the last usable deposit. If the supplier updates the production software every month but only deposits code once a year, the customer may receive something outdated and commercially useless.

The contract should deal with update frequency, for example after each major release, after material changes, or on a set periodic schedule. It should also state who bears the cost of deposit updates and whether missed updates amount to a breach under the main contract.

5. Will anyone verify the deposit?

Verification is often the difference between paper protection and real protection. Some escrow agents only hold the deposited materials without checking them. Others offer technical verification, ranging from basic file checks to a fuller build verification.

Before you accept the provider's standard terms, decide whether you need:

• a receipt confirmation only
• a completeness review
• a virus or integrity check
• a build test to confirm the software can be compiled
• a more detailed usability verification against agreed criteria

Higher verification usually costs more, but for core systems it can be money well spent.

6. What can the customer do after release?

Release rights should be broad enough to keep the business functioning, but not so broad that they become a disguised transfer of the supplier's whole product.

The post-release licence should usually address:

• whether use is limited to internal business continuity
• whether modifications are permitted
• whether a third-party developer can be engaged to maintain or adapt the software
• whether the customer can host, copy and back up the code
• whether affiliates can use the software
• whether the customer is barred from commercialising or reselling the code

If the customer needs ongoing support from a replacement provider, the wording should allow that. This point is often missed, and it matters most when things have already gone wrong.

7. How does escrow fit with privacy, security and confidentiality?

Escrow materials can include sensitive technical information, credentials and architecture details. The agreement should therefore work alongside confidentiality obligations, information security controls and any privacy requirements that apply to the software environment.

Where personal information is involved, think carefully before release about access controls, incident response obligations and whether credentials should be rotated after release. The contract should avoid creating a situation where business continuity is achieved at the cost of a security failure.

Common Mistakes With Source Code Escrow Agreement

The most common mistake is treating escrow as a box-ticking exercise instead of a working contingency plan.

Relying on vague release triggers

Terms like “failure to support the software” can sound sensible, but they may be too uncertain in a real dispute. The agreement should connect release to objective events, cure periods and evidence requirements. Otherwise, the parties can spend weeks arguing while the customer's system remains unsupported.

Depositing incomplete materials

Many businesses discover too late that the deposit did not include scripts, configuration details or third-party dependencies needed to run the system. The code is there, but it cannot be built or deployed.

This is especially common where the software evolved quickly, was built by contractors, or depends on undocumented workflows. A practical deposit schedule is usually better than a one-line definition.

Forgetting open source and third-party rights

Not every component inside a software product can be handed over or relicensed freely. Some components are subject to open source licences, and others may sit under commercial third-party terms. The escrow arrangement should reflect those legal limits rather than pretending the supplier can grant rights it does not have.

Leaving the main contract out of sync

A customer may negotiate strong escrow rights, then sign a support agreement that lets the supplier suspend services more easily than expected, or a licence agreement that restricts post-release use too heavily. Escrow should not be reviewed in isolation.

Before you sign, line up the escrow agreement with:

• the software licence
• the SaaS or hosting agreement
• the development agreement
• the support and maintenance terms
• any service level agreement
• any IP assignment or contractor deed relevant to the codebase

Ignoring practical business continuity needs

Founders sometimes focus on the dramatic event, such as insolvency, but not the practical next day problem. Who can access the released code? Where will it be hosted? Does the customer have a replacement developer lined up? Are there passwords, certificates or cloud settings needed to make anything work?

A good escrow arrangement supports an actual continuity plan. It does not just create a legal right that is too messy to use.

Assuming escrow is always the right answer

Escrow is useful, but it is not universal. In some deals, a broader licence, better transition assistance obligations, stronger service credits, step-in rights, or a requirement for documented handover materials may offer better value. The right structure depends on how critical the software is, how replaceable it is, and how much leverage the parties have in negotiations.

FAQs

Is a source code escrow agreement legally required in New Zealand?

No. It is a commercial risk management tool, not a legal requirement. Businesses usually negotiate it where software continuity is important and the customer depends heavily on the supplier.

Does the customer own the source code after release?

Usually not. Release normally gives the customer a limited licence to use, maintain and sometimes modify the software for business continuity. Ownership stays with the supplier unless a separate contract says otherwise.

Can SaaS software be covered by escrow?

Yes. Escrow can be used for SaaS arrangements, but the deposit may need to include more than code, such as deployment instructions, database schemas, configuration materials and access information needed to operate the hosted environment lawfully and securely.

What release events should a customer ask for?

That depends on the deal, but common examples include insolvency, ceasing business, failure to provide contracted support, and material breach not fixed within a set cure period. The best triggers are specific and evidence-based.

Who pays for the escrow agent and verification?

There is no fixed rule. The parties can split the cost, or one side can pay. The contract should also say who pays for updates and any technical verification services.

Key Takeaways

• A source code escrow agreement helps protect business continuity where software is critical and not easily replaceable.
• The agreement should clearly state who owns the code, what materials must be deposited, and how often deposits are updated.
• Release triggers need to be specific, workable and aligned with the main software, support and development contracts.
• Verification matters, because an untested deposit may be incomplete or unusable when a problem arises.
• Post-release rights should let the customer keep operating the software without unintentionally transferring broader IP rights than intended.
• Privacy, confidentiality, security and third-party licensing issues should be addressed before you sign, not after a release event occurs.

If you want help with release triggers, software licence terms, IP ownership, escrow deposit obligations, or a contract review, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.