§01/CLOUD REPATRIATION
Cloud Repatriation
The question is not whether to leave, but whether your infrastructure position five years from now is defensible. We model the economics of cloud repatriation, engineer the exit, and hand your team a cluster they can operate — built to leave the hyperscaler, not to depend on us.
§01/THE CASE
When the exit is worth engineering
Hyperscaler managed services are a legitimate starting position. They remove control-plane burden when a team is validating product-market fit and the cost of operational responsibility outweighs the cost of concentration. The trade-off inverts at scale: egress fees compound as data volume grows, managed-service pricing follows a different curve than bare-metal economics, and audit requirements in regulated environments routinely ask questions that hyperscaler compliance artefacts answer partially or not at all.
Cloud repatriation makes sense when three conditions converge: compute spend is predictable and sustained enough to support owned infrastructure economics; data residency or audit requirements place constraints on which infrastructure providers can hold production data; and the team has enough operational maturity to manage the cluster on-call — or wants to build that capability deliberately. When those conditions are absent, the managed path is often correct. We model the trade-off per workload before committing to a direction.
40–65%
TCO reduction (representative range)
vs. comparable managed-cloud footprint after 24 months of stable operation on self-operated Kubernetes
§02/DATA GRAVITY
The structural cost of staying
Egress fees are the tax that hyperscalers never advertised on the bill of materials. Moving data out of a managed environment — to a partner, to an analytics pipeline, to a backup location, to a regulatory examiner — costs money per gigabyte at rates that bear no relationship to the actual network cost of the transfer. At modest data volumes, egress is a footnote. At scale, it is a meaningful line item in the infrastructure budget and a structural constraint on architecture.
Data residency requirements impose a different pressure. Regulated industries — healthcare, payments, government, legal — frequently encounter requirements that data not leave a defined geographic boundary, or not transit infrastructure operated by specific providers. Hyperscaler data-residency guarantees are contractual, not architectural; the underlying infrastructure may satisfy the letter of the requirement while violating its intent. Owned infrastructure — bare metal in a defined facility — satisfies both.
The combination of egress economics and residency requirements creates the gravity well: once data is in the hyperscaler environment, the cost of extraction rises continuously. An exit-ramp engineering approach addresses this by designing data paths that are extractable from day one — not as an afterthought. This is the EXIT-RAMPS-DESIGNED-IN pillar applied to data architecture.
§03/MIGRATION ENGINEERING
Exit-ramp architecture
Every migration we deliver starts with a decision: which workloads move, which stay, and which hybrid configuration serves the transition period. The answer is almost never 'move everything simultaneously'. Application dependencies, data volume, and team readiness create a natural sequencing. We model that sequence explicitly, assign risk ratings to each phase, and build rollback paths for every cutover decision.
The Kubernetes substrate we deliver on destination infrastructure is self-operated: Talos Linux for the node OS (immutable, API-only, no SSH surface), Argo CD or Flux for GitOps state management, Cilium with eBPF for the network layer, and Rook/Ceph or Longhorn for persistent storage. Infrastructure is expressed as code with OpenTofu so the environment can be reproduced — the definition of exit ramps designed in. Network traffic is shifted gradually using weighted routing, canary deployments, and service mesh traffic management, with validation gates between stages.
§04/ZERO-DOWNTIME
No-disruption cutover
The operational requirement we hold for migrations is zero unplanned downtime. Every migration phase uses a parallel-run period — both environments serving production traffic simultaneously — followed by a graduated traffic shift with explicit rollback gates. Planned maintenance windows are negotiated in advance and sized correctly; SLA obligations to customers are treated as hard constraints during migration planning, not aspirations.
Data migration deserves special attention. Stateless workloads move cleanly via redeployment. Stateful workloads — production databases, object storage, message queues — require a synchronisation strategy that maintains consistency between source and destination until cutover. We use replication pipelines, point-in-time snapshots, and validation checksums to verify integrity before any cutover decision. The actual cutover is a single traffic switch after a validated sync window, not a copy operation under live load.
§05/HANDOFF
Your team runs this without us
The engagement ends with a transition package, not a dependency. Runbooks are written by the engineers who built the system, validated against failure scenarios in staging, and structured for the person receiving the 3am page — not for an architecture review. Incident playbooks cover the failure modes we have seen: etcd quorum loss, compute capacity exhaustion, storage degradation, certificate expiry, and network partition. Architecture Decision Records capture every choice we made and the alternatives we considered.
We run on-call training alongside your team during the parallel-run period so the knowledge transfer is operational, not theoretical. The final deliverable is a team that has responded to real (simulated) incidents in the new environment before they take sole ownership. The measure of a successful engagement is whether your team would hire us again because they want to — not because they have to.
Deliverables
TCO model (3–5 year)
Workload-by-workload cost comparison: compute, egress, storage, staffing delta, and licence delta against the hyperscaler baseline — with confidence intervals and assumptions documented.
Architecture Decision Records
Numbered, dated records of every infrastructure choice with alternatives considered and rationale — permanent institutional memory that survives personnel changes.
Cluster bootstrap automation
Fully declarative provisioning pipeline from bare node to production-ready Kubernetes cluster in a single command, tested and documented.
Migration runbook with rollback paths
Phase-by-phase migration playbook with explicit go/no-go criteria, validated rollback procedures for every stage, and incident escalation paths.
GitOps state repository
Structured Argo CD or Flux config repo with environment promotion gates, encrypted secrets management, and PR-gated change control.
On-call runbooks and incident playbooks
Validated against simulated failure scenarios in staging — node failure, etcd quorum loss, storage degradation, network partition, certificate expiry.
Stack
Trade-off
Operational ownership vs. managed convenience — and the staffing cost nobody models
Moving workloads off hyperscaler managed services means your team — or ours, during the engagement — carries the operational burden that EKS, GKE, or AKS previously absorbed: control-plane patching, node pool management, etcd backup, and on-call for infrastructure failures. That cost is real and must be modelled honestly. The offset is equally real: compute economics at steady-state scale are substantially better on owned or leased bare metal; egress fees disappear; audit evidence is produced by your systems, not filtered through your vendor. The teams for whom this trade is favorable share two characteristics: predictable, sustained compute workloads (not spiky, unpredictable bursts), and a regulatory or data-gravity constraint the managed path cannot cleanly satisfy. For teams without those characteristics, we will say so.
Architecture
Cloud Repatriation — reference architecture
§06/FAQ
Questions, answered plainly.
The questions we hear most from CTOs, engineering directors, and founders considering a sovereignty engagement.
What triggers should make us consider cloud repatriation?
Three signals converge in most decisions we see: compute spend has reached a sustained level where the economics of owned infrastructure are favorable (typically $50K–$150K/month in cloud spend, though this varies significantly by workload mix); a data residency, audit, or sovereignty requirement that the hyperscaler's compliance artefacts do not cleanly satisfy; and a team that has reached — or wants to build — the operational maturity to manage Kubernetes on-call. When all three are present, the trade-off is usually favorable. When one or two are absent, we model the specific situation before recommending a direction.
How long does a repatriation engagement typically take?
For a single-cluster migration with three to five application workloads and no complex stateful data migration, six to twelve weeks is a reasonable range from environment scoping to production cutover. Engagements with large stateful data sets, multiple cluster targets, or regulated environments requiring parallel validation periods run longer. We scope the timeline during the assessment phase, before commitment, so the estimate is based on your actual workload — not an industry average.
What happens to our SLAs and uptime commitments during migration?
The operational requirement we hold for migrations is zero unplanned downtime. Every migration phase uses a parallel-run period — both environments serving production traffic simultaneously — followed by a graduated traffic shift with explicit rollback gates. SLA obligations to your customers are treated as hard constraints during migration planning, not aspirations. Planned maintenance windows are negotiated in advance and sized correctly.
Do we need to move all workloads, or can we run a hybrid?
Selective migration is often the right answer. Not every workload has the same economics or the same residency requirements. We typically recommend starting with the workloads where the argument is clearest — sustained compute, data residency requirements, or audit obligations — and running a hybrid configuration for workloads where the managed path remains the better choice. That hybrid is designed with explicit exit ramps so the remaining cloud workloads can move when the economics or requirements shift.
What does the on-call handoff actually look like?
We run alongside your team in an on-call capacity during the parallel-run period — typically four to eight weeks after the first production traffic shifts. During that time, your team responds to real events in the new environment with us available for escalation. Runbooks are validated against real failure scenarios, not written from vendor documentation. The formal handoff happens when your team has responded to incidents covering the major failure classes — node failure, etcd quorum, storage degradation, network partition — and is confident in the playbooks.
How do you handle stateful data migration without downtime?
Stateless workloads move cleanly via redeployment to the new cluster. Stateful workloads — production databases, object storage, message queues — require a synchronisation strategy that maintains consistency between source and destination until cutover. We use replication pipelines, point-in-time snapshots, and validation checksums to verify integrity before any cutover decision. The actual cutover is a single traffic switch after a validated sync window, not a copy operation under live load.
§00/The Five Pillars
Sovereignty
OWN-THE-PERIMETER
Engineering teams owning the full stack they depend on — no invisible landlords, no rented foundations.
Open source as method
OSS-AS-DISCIPLINE
Open source is a discipline of review, contribution, and independence — not a license type to tick on an audit form.
Audit-grade rigor
EVIDENCE-BY-DEFAULT
Security and compliance aren't retrofit — they are the bar that makes self-hosting safe in regulated, serious environments.
Optionality
EXIT-RAMPS-DESIGNED-IN
Anti-lock-in by architecture: every layer has a documented exit ramp so no vendor can hold you hostage.
The long game
BUILT-FOR-DECADES
Systems proportioned to outlast the tools, vendors, and leadership changes that will come in the decade after delivery.
Executive Briefing
Thirty minutes to clarify your infrastructure risk
Walk us through your vendor footprint and regulatory constraints. We will tell you honestly where sovereignty creates leverage — and where it does not. No pitch deck. No obligation.