Turn ownership into scheduled deliverables
An exit schedule should name seven packages.
- Repository: current source, history, branches, licenses, and access.
- Build: dependency locks, tool versions, commands, and artifact location.
- Infrastructure: cloud resources, domain, certificates, networking, configuration, and billing.
- Credentials: an inventory of secrets and a rotation procedure, without placing secret values in the handoff document.
- Data: schema, export, files, retention, and a completeness check.
- Operation: monitoring, alerts, backups, restores, incidents, and routine updates.
- Knowledge: architecture, known defects, integrations, vendor contacts, and support history.
Each package needs a delivery date, owner, format, acceptance test, and procedure for keeping it current.
Distinguish possession from usability
A zip file delivered on termination may technically contain source while failing the business test. It may rely on a private package, unknown environment variable, vendor-owned cloud account, undocumented database migration, or expired credential.
Likewise, a database export may omit uploaded files, identity mappings, or the meaning of status fields. A cloud-account invitation may arrive without billing control or recovery contacts.
The NIST contingency-planning guide is scoped to federal information systems, not private software contracts. Its separation of roles, recovery procedures, testing, and plan maintenance still illustrates why an untested artifact is not a demonstrated recovery capability.
Garden's customer-cloud architecture is one first-party example of a provider making possession boundaries more specific. It identifies customer-controlled application source, images, runtime, data, secrets, logs, and infrastructure state while keeping Garden's platform source in a separate distribution project. The same page warns that portability still depends on understanding application dependencies, data formats, and how to operate without Garden; the inventory is useful contract evidence, not a completed exit drill.
Run the replacement-operator test
Before final payment—or at a recurring annual checkpoint—give a qualified person who did not build the application thirty days to answer:
- Which revision is live?
- Can I produce the deployable artifact?
- Can I deploy it to a non-production environment?
- Can I retrieve and restore representative data?
- Can I find a failed critical workflow?
- Can I rotate one non-production credential?
- Can I identify third-party obligations and current costs?
The test need not expose production secrets or disrupt users. It should reveal whether the handoff is operationally coherent.
Price the termination path
Write down:
- notice periods;
- included handoff hours;
- rates and approval for additional assistance;
- account-transfer timing;
- data-export timing and format;
- the overlap period with a replacement;
- deletion commitments; and
- how disputes affect continued access.
These are commercial questions, not legal advice. Ask counsel to review material ownership, intellectual-property, confidentiality, liability, and termination language.
Use a simple acceptance statement
Replace “customer owns all source code” as the entire plan with an operational statement:
A replacement operator can build the current revision, deploy it to a customer-controlled environment, restore representative data, identify required services, and assume monitoring using the delivered materials.
The contract can allocate rights. The exit drill demonstrates whether those rights can be exercised.