Taller Together Ep 6 | Escrowsure | When Vendors Vanish, Collections Still Move

Taller Together Ep 6 | Escrowsure | When Vendors Vanish, Collections Still Move

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

 

Update cookies preferences