Software Escrow: Protect Your Business If a Supplier Fails

Your business may rely on one software provider for payroll, customer records, ecommerce, stock control, bookings, or a core internal system. That works well, until it doesn’t. If the supplier shuts down, stops supporting the platform, goes into insolvency, or simply refuses to cooperate in a dispute, your business can be left with a system you cannot maintain and data you cannot properly access. That is where software escrow becomes a practical risk management tool.

A few mistakes come up often. Businesses sign the software contract without checking who owns the source code. They assume a cloud platform means escrow is unnecessary. They agree to vague “continuity” wording without setting out when release happens or what materials must be deposited. This guide answers what software escrow is, when New Zealand businesses should ask for it, what should go into the escrow arrangement, and the common traps to avoid before you sign a contract or spend money on setup.

Overview

Software escrow is an arrangement where important software materials are held by an independent third party and released if agreed trigger events occur, such as supplier insolvency or failure to support the software. For a customer business, the goal is business continuity. For a software supplier, the goal is to offer comfort to customers without handing over valuable intellectual property unless clearly defined circumstances arise.

• Confirm exactly what is going into escrow, such as source code, build instructions, system documentation, credentials, deployment scripts, and version history where needed.
• Match the release triggers to real business risks, including insolvency, cessation of business, material breach, failure to maintain, or prolonged service interruption.
• Check that the customer’s post-release rights are clear, including rights to use, maintain, modify, and appoint a replacement developer.
• Make sure deposits are updated after major software releases, patches, or architecture changes.
• Review the main software contract, support agreement, hosting terms, privacy obligations, and any IP licence together, not in isolation.

What Software Escrow Means For New Zealand Businesses

Software escrow gives a business a fallback position if critical software becomes unavailable or unsupported.

In plain English, escrow sits between the software supplier and the customer. The supplier places certain materials with an independent escrow agent. If specific events happen, the escrow agent can release those materials to the customer under agreed conditions.

For New Zealand businesses, this matters most where software is business-critical. That could be a custom-built platform, a heavily customised SaaS product, a point of sale system, warehouse software, a patient booking platform, or a tool that integrates deeply with your operations.

What usually goes into software escrow

The main asset is often the source code, but that is rarely enough on its own.

A useful escrow package may include:

• source code for the current production version
• build and compile instructions
• technical and user documentation
• deployment scripts and configuration information
• database schemas and interface specifications
• administrator manuals and support procedures
• details of third party components and dependencies
• access credentials or procedures for obtaining them, where appropriate and secure to do so

If a supplier deposits only raw code without the tools or instructions needed to make it work, the escrow may offer little real protection. This is where founders often get caught. They think “source code escrow” solves the problem, but the released material is not enough for another developer to take over.

How escrow differs from ordinary access rights

Access to a hosted system is not the same thing as software escrow.

Many software agreements give the customer rights to use the platform while the contract is on foot. That helps for day to day operations, but it does not usually give the customer rights to the underlying code, development materials, or long term maintenance if the supplier disappears.

Escrow also differs from a simple backup arrangement. A data backup may help you retrieve your business records, but it may not help you keep the software itself functioning. If your business depends on the application, not just the data, that distinction matters.

Why this matters in a New Zealand commercial context

New Zealand SMEs often buy software from smaller specialist vendors, local developers, or overseas providers with limited local presence. That can be commercially sensible, but concentration risk is real. If one founder-developer leaves, the company is sold, or support dries up, a customer may have few practical options.

Your contract rights matter, and so does the structure of the deal. If the software supplier is licensing IP, hosting data, providing support services, and integrating with other systems, the escrow terms need to line up with each of those pieces. You may also need to consider privacy obligations if personal information is involved, especially where access, hosting, and security arrangements could change after release.

Another point is ownership. Some businesses pay a lot for software development and assume they own the resulting code. That is not always correct. Ownership depends on the contract. Escrow can be relevant whether the customer owns the IP, licenses it, or receives limited rights on release, but the legal position should be documented clearly before you sign.

When This Issue Comes Up

Software escrow usually comes up when a business is relying on software that would be hard, expensive, or risky to replace quickly.

You do not need escrow for every software subscription. A standard off the shelf tool with easy migration options may not justify the cost or complexity. The issue becomes much more important where the software is tailored, deeply integrated, or essential to service delivery.

Common scenarios where escrow makes sense

Escrow is often worth discussing in situations like these:

• you are licensing custom software built for your business
• you are paying for a bespoke ecommerce, logistics, booking, or ERP platform
• the supplier is a small software company or single founder business
• switching to a new provider would take months, not days
• the platform handles regulated, sensitive, or operationally critical data
• the software supports customer facing services where downtime would damage revenue or reputation
• you are entering a long term managed services or support arrangement tied to the supplier’s proprietary system

Founder moments when this risk becomes real

The risk tends to become obvious at practical decision points, not in abstract legal planning.

For example, you may be about to sign a major software agreement and realise the supplier has no local team and no clear continuity plan. Or you may be renewing a support arrangement after repeated outages and want a safety net before you commit to another term.

Another common moment is investment or procurement diligence. An investor, bank, or major customer may ask what happens if the platform provider fails. If your answer is “we trust them”, that may not be enough. Escrow gives a more concrete response.

Cloud software can still create escrow risk

Using a cloud product does not remove the need to think about escrow.

Businesses sometimes assume that because software is hosted online, continuity is the supplier’s problem. But if the supplier loses funding, disables access, or stops maintaining the system, your business still bears the commercial impact. Depending on the product, a sensible solution might be source code escrow, data escrow, access arrangements for hosting infrastructure, or a mixture of these.

For SaaS products, the key question is not whether the software sits on your server or theirs. The key question is what your business needs in order to continue operating if the supplier can no longer perform.

Situations where escrow may be less useful

Escrow is not always the best answer.

If your software stack is built mainly from widely available platforms with standard export tools and multiple replacement vendors, a well drafted exit and transition clause may matter more than escrow. The same may be true if the software depends heavily on third party services that cannot legally or practically be transferred through escrow.

Sometimes the real issue is not source code access but data portability, API continuity, service levels, or rights to continued use during a dispute. A business can waste time negotiating escrow while missing the more immediate operational protections it actually needs.

Practical Steps And Common Mistakes

A good software escrow arrangement is specific, current, and tied closely to the rest of your contract documents.

The legal drafting should answer a basic commercial question: if the supplier fails, what exactly can the customer get, when can they get it, and what are they allowed to do with it?

1. Define the release events properly

Release triggers are the heart of the deal. If they are too narrow, the customer may never get access when it is really needed. If they are too broad, the supplier may feel they are giving away core IP too easily.

Common release events may include:

• insolvency, liquidation, receivership, or ceasing business
• failure to provide agreed support or maintenance for a stated period
• material breach of the software agreement that is not remedied
• permanent discontinuation of the software product
• failure to meet availability or disaster recovery obligations in a critical way

The wording should also deal with evidence and process. For example, who decides whether a release event happened, what notice is required, and how disputes about release are handled.

2. Be precise about what gets deposited

One of the most common mistakes is describing the deposit too loosely.

“Latest source code and documentation” sounds fine until release happens and no one can identify the right repository, build environment, keys, or dependencies. The deposit schedule should be detailed and, where possible, versioned.

If the software uses open source components, third party libraries, external APIs, or hosted infrastructure, the arrangement should identify those dependencies and any limits on the customer’s ability to recreate the working environment after release.

3. Set update obligations

An escrow deposit is only valuable if it stays current.

Your agreement should say when updates must be made, such as after each major release, after material feature changes, or at regular intervals. It should also say how the escrow agent confirms receipt and whether verification services are available.

Without update obligations, the customer may receive old code that no longer matches the live system. That can make the escrow almost useless.

4. Deal with verification, not just storage

Storage alone does not confirm that the deposited materials are complete or workable.

Where the software is truly critical, consider whether the escrow arrangement should include some level of verification. That might involve checking that files are readable, confirming the deposit is complete against a schedule, or carrying out technical testing to see whether the code can be built according to the supplied instructions.

The right level of verification depends on budget and risk. Not every SME needs full technical testing. But for high dependency software, no verification at all can be a false comfort.

5. Match the release rights to your actual needs

Release is only part of the story. The customer also needs a licence or other rights that let them use the materials after release.

The post-release rights should address matters such as:

• whether the customer can use the source code internally
• whether the customer can modify and maintain the software
• whether a replacement developer or IT provider can access the materials
• whether the rights are limited to business continuity purposes
• whether sublicensing is prohibited except to service providers acting for the customer

This should be aligned with the main IP clause in the software contract. If one document says release grants maintenance rights, but another says no modification is allowed under any circumstances, you have a problem.

6. Consider privacy, confidentiality, and security

Escrow arrangements often involve sensitive material. The supplier will want strong confidentiality controls, and the customer should too.

If the software processes personal information, your business should think carefully about what data, credentials, or environment details are included in the deposit. Privacy Act obligations, internal access controls, and information security practices still matter. In many cases, it is better for escrow to include system materials and clear procedures for secure handover, rather than unnecessary copies of live personal data.

7. Do not ignore the rest of the contract

Escrow does not replace a good software agreement.

Before you sign, review the broader terms around service levels, support, data export, transition assistance, IP ownership, warranties, limitations of liability, termination rights, and dispute processes. If those clauses are weak, escrow may not fill the gap.

For example, a customer may focus heavily on source code release while forgetting to secure rights to its own data in a usable format. Or a supplier may agree to escrow but keep a broad right to suspend services on short notice for payment disputes, creating continuity risk anyway.

Common mistakes businesses make

The most frequent errors are commercial as much as legal.

• assuming escrow is only for large enterprises
• waiting until after a dispute starts to ask for it
• treating cloud software as risk free
• failing to identify third party dependencies
• omitting update and verification obligations
• focusing on release triggers but not post-release usage rights
• forgetting to align escrow with privacy, hosting, and support arrangements

A practical approach is to start with business continuity. Ask what your business would need in the first 30 days if the supplier vanished. That usually exposes what the escrow arrangement and wider contract need to cover.

FAQs

Is software escrow only relevant for custom software?

No. It is most common for custom or heavily customised software, but it can also be relevant for SaaS platforms where your business relies on the supplier’s ongoing support and access to the application is critical.

Does software escrow mean the customer owns the source code?

No. Escrow does not automatically transfer ownership. It usually gives the customer conditional access and limited rights to use the deposited materials if release conditions are met. Ownership depends on the main contract and any IP assignment or licence terms.

What release events should a New Zealand business ask for?

That depends on the deal, but common events include insolvency, ceasing business, failure to provide support, material breach that is not remedied, or discontinuation of the software. The right triggers should reflect the real commercial risks in your arrangement.

Is data backup the same as software escrow?

No. A backup helps recover your information. Software escrow is about access to the underlying software materials needed to maintain or continue operating the system. Many businesses need both, not one or the other.

Can an escrow arrangement cover more than source code?

Yes. It can cover documentation, deployment tools, configuration details, database schemas, credentials handling procedures, and other materials needed for continuity. In some cases, a broader continuity arrangement is more useful than source code alone.

Key Takeaways

• Software escrow helps protect your business if a software supplier fails, stops supporting a system, or cannot continue providing access.
• The most useful escrow arrangements define clear release events, detailed deposit contents, update obligations, verification steps, and post-release usage rights.
• Cloud software can still create escrow risk, especially where the platform is deeply integrated or hard to replace.
• Escrow should be reviewed alongside your software contract, support terms, hosting arrangements, data access rights, privacy obligations, and IP clauses.
• The main goal is business continuity, not just possession of source code.

If your business is dealing with software escrow and wants help with supplier contracts, intellectual property rights, SaaS terms, privacy issues, or a contract review, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.