How Escrow
Keeps Systems Survivable
Key Insights to Remember:
- Vendor
failure is governance, not IT.
- · Risk
translated into enforceable rights
- Trigger
events must be explicit.
- A fallback licence is non-negotiable.
- Source
code alone is insufficient.
- Verification
proves recoverability.
- Mirror
builds reveal hidden gaps.
- Evidence
that satisfies trustees
- SaaS
needs environment capture.
- Escrow
can strengthen vendor trust.
What
Does Software Escrow Mean for Cultural Custody?
Museums already know how to protect objects. They monitor light, temperature & movement and keep insurance and valuations current. But the day-to-day record of what an
artwork is, where it is, what can be done to it, and who can touch it
increasingly lives inside software the institution does not own and cannot
fully inspect.
In a Taller Together conversation hosted by Tamzin Lovell, EscrowSure’s
Anthony Watson and Guy Krige treat that as a governance problem, not an IT
footnote. The point lands because it is boring in the right way. The risk is
ordinary. Vendors fail. Contracts end. Priorities shift. People disappear. A
collection still has to move.
One story in the episode is familiar enough to be unsettling. A
mid-sized museum was locked out of its catalogue when a vendor folded. The
staff could not access the system that anchored loans, movements, condition
notes, and internal accountability. As framed in the interview, this was not a
technical surprise. It was a governance gap that everyone had learned to
ignore.
Software escrow is not a magic shield. It is a legal and operational
mechanism that makes continuity enforceable. If you treat collection data as
institutional memory, escrow is one of the few tools that turns trust into a
plan you can test.
Why Do Cultural Organisations
Misread Software Risk?
Most organisations still work off a comforting assumption: if something
is cloud-hosted, it is stable; if a vendor is responsive today, they will be
responsive tomorrow. The episode pushes against that default. Vendor
insolvency, acquisition, strategic pivots, and slow abandonment are not rare
events. They are normal outcomes in a market where platforms are built, sold,
merged, and sunset.
The risk is not only losing a tool. It is losing the connective tissue
that makes collections legible and governable.
What tends to break first is not the data itself, but the ability to use
it safely:
- Provenance chains and supporting
records become inaccessible at the moment scrutiny increases.
- Donor restrictions and internal
approvals become difficult to prove.
- Conservation notes and movement
histories lose their operational context.
- Audit trails become partial or unverifiable.
- Staff revert to manual
workarounds while still carrying the same public obligations.
That is when reputational damage starts. Trustees and lending partners
do not ask whether your vendor had a tough quarter. They ask why the
institution did not have a survivable plan for core records.
What Problem Does Software Escrow Actually Solve?
A good definition from the conversation is simple: escrow translates
risk into rights.
In practice, a neutral escrow agent holds the materials needed to keep a
software product running and releases them only if specific trigger events
occur. The escrow agreement defines those triggers, the deposit contents, the
verification process, and the licence terms that govern what the customer can
do after release.
This matters because in a real failure scenario, goodwill is not a
control. If the vendor cannot respond or will not respond, your relationship
history stops being relevant. Escrow creates a continuity pathway that does not
rely on the vendor’s availability or enthusiasm.
Three elements do most of the work:
- Explicit trigger events
- A fallback licence that makes the released materials usable
- A release process that is fast and enforceable
If one of these is vague, the whole structure becomes performative.
What Makes Escrow Real Instead
of Shelfware?
A common misconception is that source code equals recoverability. It
often does not. Code without build steps, dependencies, configuration, and
environmental details can be technically “released” and practically useless.
The episode is clear about the gap between possession and operability.
What you need in a crisis is not a folder of files. You need the ability to
rebuild, run, and maintain the system long enough to transition.
The conversation also points out something vendors sometimes miss:
verification is not only for the buyer. It is a stress test of the vendor’s own
discipline. When you assemble a deposit that can be rebuilt outside your
internal environment, you surface undocumented assumptions and brittle
processes. Fixing those gaps makes you more reliable even before any escrow
trigger is ever pulled.
For collection systems and similar operational platforms, a credible
deposit typically includes:
- Source code plus dependency
manifests and build tooling
- Deployment instructions that a
third party can follow
- Configuration guidance that
separates secrets from settings
- Infrastructure specifications
and runtime requirements
- Documentation for integrations
and data interchange
- A verification schedule with
written outputs that can go into governance packs
The verification piece is where escrow becomes real. It turns a
contractual promise into evidence.
How Does Escrow Land With
Trustees, Audits, And Compliance?
Boards rarely want a lecture on architecture. They want a defensible
answer to one question: what did we do to ensure continuity of core records?
In the episode, the legal angle is direct. Trustees carry responsibility
for governance, and in many settings, they can carry personal exposure when
basic risk management is neglected. That is why “we trust the vendor” does not
satisfy in a bad outcome review.
Escrow maps neatly to risk frameworks because it produces artefacts:
defined triggers, defined recoverability conditions, and auditable verification
results. It also fits alongside common information security governance
approaches. If you already report on information security and continuity
controls, escrow provides a specific mechanism for a specific dependency.
There is also a softer benefit that matters in cultural organisations.
Escrow can calm internal tension between teams. It stops procurement from being
framed as faith versus fear. It becomes a documented decision with clear
contingencies.
What Should Museums Ask For
When They Sign a Software Contract?
Most procurement processes still overweight features and support
promises, then underweight exit and failure pathways. The episode offers a
clean way to rebalance.
When you are evaluating a platform, ask questions that force operational
clarity:
- What are the trigger events for
release, and who determines that they have occurred?
- What exactly is deposited, and
what is excluded?
- How often is the deposit
updated?
- What verification is performed,
and what evidence do we receive?
- What is the fallback licence,
and does it cover subcontractors and third-party components?
- What is our operational plan
post-release, rebuild, host, or transition?
- How do we get our data out in a
structured, reusable form even without escrow release?
A vendor who treats these questions as hostile may not be the vendor you
want holding your institutional memory. The episode makes a useful counterpoint
here: escrow is not an accusation. For serious suppliers, it is a trust signal.
It says the vendor understands the client’s obligations and is willing to
support continuity in enforceable ways.
The conversation ends with an image that works precisely because it is
not a metaphor you can tidy up. Krige describes sitting with Monet’s Water
Lilies at the Musée de l’Orangerie, letting the room slow down. The tension is
that we care for paintings through routines and redundancies, yet we still
allow the systems that describe them to run on faith.
References And Further Reading