Run a vendor exit drill before the exit is urgent

Define what must survive

A vendor exit is not the same as downloading files. List the business capabilities that must continue: receiving new work, finding historical records, editing active items, running automations, proving approvals, and meeting internal retention needs. Then inventory the system's data, attachments, comments, users, permissions, integrations, webhooks, domains, credentials, scheduled jobs, and billing owner.

This drill is broader than exporting one knowledge project. It tests whether the operating system around the data can be reconstructed. Microsoft Power Platform's dependency documentation is a useful concrete example: exports can warn about missing components, and imports can fail when required dependencies are absent. Every vendor represents dependencies differently, so the inventory must be local and explicit.

Inspect formats before trusting them

Prefer documented, machine-readable formats, but do not assume CSV means complete. Relationships may be split across files, formulas may become values, and proprietary blocks may be omitted. Record a field-level loss list. If the platform provides an application package, keep the raw package and also export human-readable records where possible.

Restore representative work

NIST's contingency-planning guide treats backup as part of recovery and says testing helps determine whether procedures are viable and reveals deficiencies. Apply that discipline to exit. Choose representative records: an old completed project, an active item, a record with attachments, a complex permission case, and a workflow with integrations. Import or reconstruct them in a separate destination and have a normal user locate and use them.

A hypothetical small agency might export client projects successfully but discover during restore that comments lack authors, recurring jobs are absent, and attachment links point to the old tenant. The drill has succeeded by finding these gaps before cancellation. It has not proved every record will migrate perfectly.

Run in parallel long enough to reconcile

1. Freeze configuration changes or record them in both systems.
2. Perform the documented export and hash or inventory the files.
3. Restore the representative set in the destination.
4. Reconcile counts, key fields, attachments, and access.
5. Route a bounded slice of new work through the replacement.
6. Document losses, manual conversions, and owners.

Keep the source available while discrepancies are investigated. Define the final delta export if records can change during migration. Confirm what the vendor retains after cancellation and how deletion is requested, but avoid making legal conclusions from marketing copy; escalate contractual or regulatory questions to qualified counsel.

Disconnect last, in a controlled order

After acceptance, stop incoming triggers, revoke OAuth grants and API keys, remove service accounts, update domains or webhooks, transfer billing ownership where needed, and cancel the plan. Watch for failed calls from forgotten integrations. Preserve the export, reconciliation record, dependency map, and cancellation evidence according to the team's retention policy.

Microsoft's flow-export documentation says a movable solution should include connection references, environment variables, tables, and other components it uses. That is the practical lesson: data, logic, configuration, and connections travel together or fail separately. An exit drill is complete when representative work functions in the new place and the old place can be disconnected without guesswork.