A regulated payments platform

The platform processed regulated payment flows across three EU jurisdictions. Over four years it had drifted — not by design but by compounding convenience — into a single hyperscaler's managed Kubernetes, object storage, secrets management, message queuing, and networking products. Each quarter the surface deepened: managed Redis caches, proprietary event buses, vendor-native audit logging, managed certificates. By the time a Series-C diligence process began, the infrastructure was effectively insoluble from one provider's control plane. The dependency graph was not just broad; it was structurally silent. When the team first mapped it, they found that several production systems had direct SDK integrations with proprietary vendor APIs — not cloud-agnostic interfaces, but APIs that only existed on one cloud. Removing the provider would have required rewriting not just infrastructure configuration but application code. That discovery changed the frame of the engagement from "how do we reduce costs" to "how did we get here and how do we build something we actually own."

The diligence team flagged three risks that landed in the board pack within ten days of the process opening. First, concentration risk: a single provider failure, pricing change, or contractual dispute could halt payment operations with no viable fallback and no tested recovery procedure. The team had never rehearsed a provider-level failure; their DR documentation assumed the provider's control plane was available. Second, egress economics: cross-region data transfer and external-service egress had grown to consume a material percentage of gross infrastructure cost. Projections based on transaction growth showed this compounding to an operationally painful number inside eighteen months, with no architectural lever to reduce it without a significant migration. Third, data-residency accountability: the lead investor had relationships with regulated counterparties in multiple jurisdictions who required documented, auditable data-residency guarantees. The managed cloud services in use could not produce those guarantees in the specific form those counterparties required — the provider's residency attestations covered the service tier, not the specific data path, which was not sufficient.

The team's position was not ideologically anti-cloud. Several engineers had built their careers on managed services and understood the operational leverage they provided. The question they needed answered was precise: what is the cost of concentration, and can we architect our way to a position where we own the answer to that question? That reframing — from "cloud vs. on-prem" to "do we own the answer" — shaped every subsequent decision.

The payment processing pipeline had uptime SLAs embedded in the platform's largest contracts. Any exit architecture had to support incremental migration with zero planned downtime; live traffic could not pause for a cutover window of any duration. That ruled out the simplest approaches (stand up a replacement cluster, do a big-bang cut) and required a migration model where both platforms ran simultaneously, with traffic shifted at the service level, not the cluster level.

The engineering team was strong on application development but had limited depth in bare-metal Kubernetes operations. They had never managed physical network configuration, storage provisioning, or cluster upgrades outside a managed service. Any platform handed off at the end of the engagement had to be operable by that team — with documented runbooks and clear failure-mode procedures — without requiring ongoing specialist support.

A third constraint was compliance evidence. The existing environment had grown without a systematic audit trail. Change history lived in a mix of Terraform state files (some of them manual-drift-corrected), Slack threads, and the provider's activity logs — which were not exportable in a format that would survive regulatory scrutiny at the next scale tier. The replacement architecture had to produce compliance evidence as a structural byproduct, not as a retrofit bolted on later.

Finally, the target architecture needed to be financially legible to the CFO and defensible to the board. The decision was not just technical; it had to hold up in a board presentation where someone would ask "why are we doing this ourselves instead of letting the cloud provider do it?" The answer required a TCO model that was honest about the fully-loaded cost of self-operation, including team time.

The first two weeks were spent on a perimeter map: every cloud service in the production environment, its role in the payment path, its data-residency posture, the blast radius if it became unavailable overnight, and the vendor-specific API surface the application code depended on. This produced a ranked dependency graph — not an opinion about cloud versus on-prem, but a factual inventory of what the team owned and what it rented, and what each dependency cost to exit.

From that graph we identified three categories. Category one: services that carried payment data or were in the critical path for transaction processing. These had to move to sovereign infrastructure. Category two: services with no direct data dependency — CDN, DDoS absorption, burst compute for non-sensitive batch jobs. These could stay at the cloud edge indefinitely; the economics and operational simplicity were genuinely better there. Category three: proprietary vendor APIs embedded in application code. These needed replacement before infrastructure migration was even possible; you cannot move a workload to a different platform if the workload calls a proprietary API that only exists on the old platform.

We designed the exit as a deliberate hybrid. A sovereign core — owned Kubernetes on Talos Linux, running in co-location racks in each required jurisdiction — handled all payment-path components and persistent data. A thin cloud edge (CDN, DDoS, burst) handled non-sensitive workloads, was stateless, and was written with no data dependency, making it replaceable in under a week if needed.

Exit ramps were designed into every layer at the start, not added as an afterthought. Each infrastructure component was selected with an explicit answer to "how do we replace this in ninety days if we need to?" The answer was documented in the runbook alongside the component before the component was deployed. This was not theoretical: we ran a tabletop exercise on each exit ramp to verify the procedure was complete enough to execute under pressure.

The migration sequence ran bottom-up: networking and secrets first (no application dependency, purely platform plumbing), then stateful workloads (databases, queues), then stateless application services, then traffic shifting. At each stage, the old and new paths ran in parallel with traffic at the old path until the new path was validated under production load. The final traffic shift was incremental: 1% → 10% → 50% → 100% over a three-week window, with automated rollback triggers if error rates deviated.

Within eighteen months, all payment-path components were running on the sovereign core. The cloud edge remained for CDN and burst compute but carried no state and no PHI-adjacent data; replacing it was a configuration change, not a migration project. The diligence questions that had stalled the Series-C were answered with evidence — architecture diagrams, policy-as-code exports, GitOps commit history, and a tested DR runbook — rather than vendor SLA screenshots and attestation letters.

Representative outcomes across comparable engagements (not precise client figures): Infrastructure cost trajectory reversed. Instead of compounding egress fees and managed-service price increases tracking transaction volume, costs became largely fixed and predictable. Across comparable engagements, the three-year TCO of the sovereign architecture is typically 40–60% lower than the prior trajectory, depending on the specific managed service mix being replaced and the transaction growth rate.

Zero single-vendor hard dependencies remained in the payment path after full migration. Each infrastructure component had a documented successor and a tested migration procedure.

Every infrastructure layer had a documented, rehearsed exit ramp. The concentration risk that had appeared in the board pack as an open question was answered with a procedure, not a hypothesis.

The compliance audit the following year required no emergency evidence collection. The GitOps commit history, the Argo CD sync log, the Cilium network policy exports, and the Loki audit pipeline were the audit trail by default — queryable, structured, and in the format the auditors expected.

The thin cloud edge (CDN, DDoS absorption, burst compute) — because it carried no state, the economics were genuinely better there, and the optionality to replace it was preserved by design. The application layer was unchanged; every service ran the same container images on the new platform. The engineering team owned and operated the sovereign platform independently from month six onward. No Stribog dependency remained in the day-two operations path. The runbooks, exit-ramp documentation, and GitOps repository belong to the team. The TCO model used for the board presentation has been updated twice since the engagement ended, by the team's own engineering leadership.