Moving Customers From Cloud Rent to Ownership
Most businesses sell usage; the sovereign stack sells ownership. The migration service is the mechanism that moves a customer from renting infrastructure in the cloud to owning it on their own terms — local-first, key-scoped, verifiable. The S6.2 article described the sovereign AI stack; the S6.5 migration article documented the fleet’s own move from monolith to microservices. This article is the customer-facing version: what it takes to migrate a customer’s workloads onto the sovereign stack without breaking their business.
Why migration is the hardest service to sell
Migration is scary. The customer’s systems are working — maybe not ideally, but working. Migrating means risk: downtime, data loss, behavior changes, unknown unknowns. The sales pitch “move to our stack” is asking the customer to trade a known, mediocre state for an unknown, better one. The sovereign stack’s answer to this fear is evidence: the migration is not a leap of faith, it is a series of small, verifiable steps, each one recorded in the ledger.
The migration service is therefore not “we will move your stuff.” It is “we will move your stuff in stages, prove each stage works, and give you the receipts.” The S8 simulation discipline — test small, verify, promote — applies to the customer’s migration exactly as it applies to the fleet’s own experiments.
The migration staging ladder
A migration is decomposed into stages, each with a defined entry and exit condition:
- Stage 0 — Assessment. The fleet inventories the customer’s current workloads: what runs, what data exists, what the dependencies are, what the actual costs are. The assessment is itself a deliverable with evidence — the customer learns what they are paying for today.
- Stage 1 — Shadow. The customer’s workloads run in parallel on the sovereign stack, in shadow mode, producing outputs that are compared to the production outputs. Nothing is cut over yet. The comparison is recorded and shared.
- Stage 2 — Pilot. A low-risk workload moves for real: a report, a publication, a dashboard. The customer uses it in production and sees the evidence trail. This is the first live proof.
- Stage 3 — Cutover. The remaining workloads migrate, one at a time, each with its own shadow-and-verify cycle. The customer’s own teams are trained during this stage — they are not handed a black box.
- Stage 4 — Operation. The customer runs on the sovereign stack, with the dashboard (S6.7), the support ladder (S6.10), and the audit slice (S7.15) as their daily interface.
The staging ladder is not optional ceremony. It is the mechanism that makes migration safe: at every stage, the customer can stop, verify, or roll back, and the ledger records what happened. A migration that skips stages is a bet; the ladder is the hedge.
The data problem: sovereignty means ownership
The hardest part of any migration is data. The customer’s data lives somewhere — a cloud bucket, a database, a file store — and moving it means trusting the mover. The sovereign answer is cryptographic: the data transfer is signed, checksummed, and verifiable at both ends. The customer can verify that what arrived is exactly what left, byte for byte, without trusting the fleet’s word.
Once migrated, the data’s ownership is structural: the customer’s tenant (S7.14) holds the keys to their data plane, and no other tenant — including the operator — holds a master key. “Your data, your keys, your sovereignty” stops being a slogan and becomes a property of the architecture that the audit slice demonstrates.
The exit clause: migration is a two-way street
The most honest thing a migration service can offer is the exit clause: the customer can migrate back out. A sovereign provider that locks customers in is not sovereign; it is a landlord. The migration service therefore includes the reverse path — export the customer’s data, revoke their keys, archive their tenant — with the same staged, verified process used to bring them in. The exit clause is not a concession; it is the proof that the customer owns their systems, not the provider.
This is the business logic behind the S6.1 digital-sovereignty-as-a-product article. Sovereignty is not a feature you bolt on; it is a property of the relationship. The migration service is where that property is first tested — and the exit clause is where it is proven.
Why the fleet can sell what it has lived
The migration service has a credibility advantage most migration consultancies lack: the fleet migrated itself. The S6.5 article documented the fleet’s own move from monolith to microservices, with the receipts. The S7.9 article documented the persistence architecture that survived restarts. The S7.11 article documented recovery from verified state. The migration playbook is not theory; it is the fleet’s own operating history, packaged for customers.
The customer is not asked to trust a methodology. They are asked to verify a track record — the same way they will verify their own migration, stage by stage, in the ledger.
Grounded in wiki concepts migration-service, local-first, cloud-optional, multi-tenancy, data-ownership, simulation-mode, and the S6 + S7 + S8 series. Design notes on a running system.
