SaaS Transport System: When the Vendor's DR Is Not Your DR

What the vendor actually owns - and what Halcyon retained

The vendor is responsible for the availability and durability of the SaaS platform within the region it chose, and for its own internal recovery. Halcyon remains accountable for:

• Business continuity of the shipping process - no vendor SLA restores Halcyon's ability to dispatch loads. That is Halcyon's continuity plan, and it should include a manual/degraded mode (spreadsheets, direct EDI, phone dispatch) with pre-agreed triggers.
• The integration layer - 14 custom scripts and scanner feeds are customer-owned code. Even if the TMS returns, dispatch stays broken until those are validated. They need source control, documentation, and an owner.
• Identity federation - the on-premises IdP is a hard dependency. If it is down or misconfigured, the recovered SaaS is unreachable for every user.
• Data retrievability and records retention - the customs audit obligation is Halcyon's, not the vendor's.

The structural point

"Vendor tests DR annually" tells you the vendor can recover its service. It says nothing about Halcyon's end-to-end recovery time, because the measured 31-hour outage already exceeded the contractual 24-hour RTO - and that figure covered only the vendor's own component. End-to-end RTO is the sum of vendor recovery, Halcyon's integration revalidation, identity restoration, and business verification. The COO's 8-hour target has to be built out of those parts, not negotiated as a single number with the vendor.

Contract first, because it is the only lever that survives the relationship

1. Data portability as a standing right. Continuous or scheduled export of Halcyon's data in a documented, machine-readable format (not CSV-on-request) to a Halcyon-controlled store. Define format, frequency, schema documentation, and a maximum latency.
2. Remedies with teeth. Service credits are not a recovery strategy. Add termination-for-convenience rights with defined data return and deletion timelines, transition assistance of 90–180 days, and configuration/script escrow if the vendor hosts customization.
3. Notification and transparency. A one-hour incident notification obligation for any Sev-1, with root-cause reporting within a defined period - the three status-page updates in 31 hours is the clause that failed most visibly.
4. Subprocessor and region commitments, including whether the vendor will support a second region or cross-region replication, and at what price.

Then technical mitigations, cheapest first

• Stand up a nightly (then hourly) export of TMS shipment and order data into object storage Halcyon controls. This immediately solves the customs audit question and provides the raw material for a degraded-mode dispatch process.
• Put the 14 integration scripts under version control with an inventory of APIs and field mappings, and test them against a vendor sandbox.
• Pre-build and rehearse a manual dispatch fallback - the realistic path to an 8-hour business RTO when the vendor's own RTO is 24 hours.
• Only then evaluate a second-region or multi-vendor architecture; it is the most expensive option and the least useful if exports and manual fallback do not exist.

Framing for the business

The 8-hour requirement is achievable for dispatch decisions via exported data and manual processes, while full TMS functionality may legitimately take 24. Present the target as two numbers, not one concession.

Test the exit, not the contract language

Run a facilitated tabletop with a blunt scenario: the vendor gives 30 days' notice and will not renew. Participants: logistics operations, IT, procurement, legal, and finance. Walk the clock day by day and force concrete answers to four questions:

1. Day 1–3: Can we obtain a complete export of current data without the vendor's discretionary cooperation, and do we know its schema without reverse-engineering? If the answer is "we will ask them," the organization is dependent on goodwill.
2. Day 4–15: Can we stand up an alternate system or manual process and re-point the 14 integrations? Who owns each script, and is it documented well enough for someone who did not write it?
3. Day 16–30: Can we satisfy customers and customs auditors during the gap - including historical shipment records from three years back, which typically do not come across in a standard migration?
4. Who decides and who signs? An exit with no named executive owner is a document, not a capability.

Evidence that would confirm entrapment

• No documented schema and no standing export right: data exists only inside the vendor's system.
• Historical records retrievable only by vendor discretion, which conflicts with the audit obligation to produce them on demand.
• Integration logic held by one person or by the vendor with no escrow.
• Business processes with no manual fallback, meaning any migration is attempted during an outage rather than ahead of it.

The output

An exit runbook with dates, owners, and a tested export - plus a prioritized list of what must be renegotiated at the next renewal. A tabletop that produces no artifacts has tested nothing.