bbyoc anywhere
X
commandment X

Exit Is a Feature

The workload and its data outlive the vendor relationship, so design exit as a configuration change.

 portable workloads, nothing to migrate
PORTABILITY: THE WORKLOAD OUTLIVES THE RELATIONSHIPsame service definition runs:hostedBYOC awsBYOC gcpBYOC azureon-premair-gappeddata, backups, and keys are already in the customer's custody (Commandment I)exit requires no migration of the crown jewelsrevocation cuts access; portability keeps the workload alive. together, a complete exit

Commandment IX gave your customer the power to revoke every credential your control plane holds. This commandment answers the question that follows: what runs the workload the next morning. Lock-in at this layer is architectural. A system that runs only one way, in only one place, keeps the customer dependent no matter how completely they cut you off. A customer who can revoke every IAM role but cannot run their database without your control plane has traded one dependency for another.

Treat portability as the last line of sovereignty. Ship one service definition that deploys to hosted SaaS, to BYOC on AWS, GCP, or Azure, to GPU neoclouds, to on-premises Kubernetes, and to fully air-gapped sites. Build the workload from standard substrate: containers, Helm charts, and declarative infrastructure that any competent operator can apply. Give every piece of orchestration your control plane performs a declarative equivalent the customer can run themselves. Moving between postures then becomes a deployment decision, and exit becomes the final posture change.

The control plane's job here is to make itself removable. It deploys, upgrades, and observes the workload, and that is the full extent of its role in the system. It must never hold the workload's data, backups, snapshots, or encryption keys, and it must never sit in the data path as a runtime dependency. Everything the workload needs to serve traffic belongs in the customer account: data on customer volumes, keys in the customer's KMS, backups in customer-owned object storage, artifacts mirrored into a customer-reachable OCI registry, and traffic flowing through customer-side load balancers (Commandment III).

Get this right and exit moves nothing. Custody of the data sat with the customer from day one (Commandment I), so there is no vendor-side copy to migrate. Leaving requires no export pipeline, no data-egress bill, and no migration project for the data. The workload keeps serving through the customer's own load balancers while the relationship winds down around it.

Make exit rehearsable. Your customer should be able to restore from their own backups and redeploy from the mirrored artifacts with your control plane out of the loop entirely, and they should be able to test that path on a schedule instead of discovering it during a dispute.