Your software supplier knows the system, handles updates and responds when something breaks. Everything is working.

But suppose the supplier became unavailable tomorrow. Could someone else keep the application running?

This can happen when a supplier closes, loses key staff, stops supporting a product or has a serious disagreement with a customer. A business might also need to change suppliers because its requirements have changed.

The time to establish what a replacement would need is while the existing relationship is working.

Could another developer take over?

Imagine a replacement developer starts on Monday morning. They receive a copy of the source code and the documentation the business has kept.

They soon discover that the production database sits in the original supplier's account. The deployment process depends on settings nobody has recorded. A commercial component is licensed to the supplier, and the latest code cannot be run without it.

The business has the source code, but the replacement cannot operate the system.

A handover needs to cover five things:

  • Code: Access to the version currently in use, including relevant configuration and dependencies.
  • Data: A way to retrieve the business's information in a usable format.
  • Accounts: Control of hosting, domains, backups and connected services, or an agreed way to transfer them.
  • Documentation: Enough information to deploy, operate, troubleshoot and recover the application.
  • Rights: Permission to use the code and third-party components after the supplier relationship ends.

These do not all need to be stored together. Some can remain with the supplier under an agreed handover arrangement. What matters is whether the business can obtain and use them when needed.

Ownership does not guarantee access

Software ownership can be complicated.

Under New Zealand copyright law, commissioned software may belong to the party that commissioned it, subject to the relevant legal rules and contractual arrangements. Existing supplier code, open-source packages and commercial components can have different terms. The Intellectual Property Office of New Zealand explains the general position.

A lawyer can advise on ownership and contractual rights. A technical review answers a different question: can the business actually exercise those rights?

A company might own the copyright in its application but have no administrative access to the service running it. It might own the database but have no tested way to restore it. It might be allowed to use a software component only while the supplier's licence remains active.

These problems are easier to resolve before a supplier becomes unavailable.

Check what the business depends on

A small website can usually tolerate more disruption than a system used to schedule urgent jobs or process orders.

The New Zealand National Cyber Security Centre's guidance on supply-chain security recommends assessing suppliers with regard to their access, the information involved and the effect of disruption.

The same approach helps determine how much handover preparation is justified.

For a modest application, company-controlled accounts, a current repository, a data export and accurate operating notes may be sufficient.

A business-critical system may justify testing whether a replacement can restore a backup or deploy a working copy in a separate environment.

The test should match the consequences of failure. If staff can operate manually for several days, the business has more time to recover. If an outage stops payments or urgent services, it needs a more demanding recovery plan.

Test the handover before you need it

Start by asking someone who does not normally maintain the application to examine the available accounts, files and instructions.

Can they identify the production version? Do they know where to find the backups? Can they explain how the application is deployed and which services it needs?

Record the missing information precisely. For example:

"The deployment instructions do not include the database update required by the current release."

That gives the existing supplier something specific to correct.

For important systems, the next step may be a controlled restore or deployment into a test environment. Agree on access and safeguards beforehand, particularly where personal information or commercial licences are involved.

A handover test should not interrupt the live service.

Make continuity part of the supplier relationship

You can discuss continuity with your current supplier without suggesting that you intend to leave.

Ask who controls each account, what happens to your data when the contract ends and what assistance the supplier will provide during a transfer. Record the answers in the contract or operating documentation.

Review these arrangements when the system changes substantially, a contract is renewed or a key person leaves. Instructions that worked two years ago may no longer describe the application.

Most businesses will continue depending on specialist suppliers. The useful question is which parts of that dependence have been agreed and which have simply gone unexamined.