Services / Cloud repatriation
When shared cloud is ruled out
Cloud repatriation & private cloud migration
We move the estate the requirement covers out of public cloud onto a private cloud we build, in waves. Each wave has rollback options in place, and the cloud side stays until you sign that wave off. When the last wave is signed off and the cloud side is decommissioned, your data sits where the requirement says.
A fixed-scope read of the estate and the cleanest path out. Paid, typically one to two weeks depending on the size of the estate, and the fee credits against the engagement if you go ahead. Not ready for that? Send us the shape of your estate and get a written reply within two business days.
Why the estate has to move
A data-sovereignty requirement, from a customer contract, a regulator, or your own policy, now says some of your data cannot sit in shared cloud. Today the estate that requirement covers is in AWS, Azure, or Google Cloud, and unless your provider can meet the requirement in another form, it has to come out.
A cloud exit can also come from an audit deadline, governance of the data behind your AI, or concentration risk: too much of the business resting on one provider.
The move puts your data where the requirement says it must sit, on a platform with controls built in. Your own organizational controls carry the rest.
If it is the bill rather than a requirement that has you looking, start with the assessment: it sizes the platform and names the cost lines a comparison needs, and its answer can be “not yet.”
Where the estate lands
The destination has to meet the needs of your business, now and later. It decides what you get: the platform’s capabilities, and so what becomes of each managed service you use today.
If you already have a platform or a shortlist in mind, tell us which and why. The assessment tells you whether what we build meets the needs behind that choice.
We build a Kubernetes-based private cloud from open-source components, on infrastructure you control: on-premises, in a colocation facility, or, where the requirement allows it, on dedicated servers you rent. We do not resell hardware and we hold no margin in what you choose. What runs as a virtual machine today can run as one on the platform, beside containers. Where the destination is a productized platform rather than a bespoke build, that is SECO, our sovereign private cloud: VMs, containers, and AI on one control plane you own.
How the move runs
We plan and run the move onto the platform we build. Before the first wave, the platform is built and tested, and the first wave starts once you have signed off those tests.
The move runs in waves, each with rollback options in place and a cutover window agreed before it starts. Each wave is signed off against checks agreed before it runs. The cloud side stays until that wave is signed off, so you pay for both platforms in the meantime. That wave’s data also stays in the cloud it is in today until the cloud side is decommissioned.
Data moves the way it is stored. Block volumes, file systems, and object storage are copied at the storage level; databases move at the database level, not as disk copies. All of it travels straight from the cloud side to your platform, encrypted in transit, and never through systems of ours. Most of it is copied while the cloud side keeps serving, so only the last changes move inside the window. The assessment works out what can move ahead of the window, and how long each window needs.
Until the new side takes its first writes, going back means switching traffic back to the cloud side, which still holds everything. After that, it means carrying those writes back to the cloud side, where the requirement and the service allow it, or giving them up. The choice for each part of the data is agreed with you before the wave runs, and carrying writes back is part of the work.
From the first cutover, the platform is run as it will be after the move: by your team, or by us.
How many waves, and over what period, is a property of your estate rather than a number we can publish.
What each managed service becomes
The managed services the estate uses from your provider each get one of three decisions in the assessment: rebuilt on the platform, kept where the requirement allows, or retired.
Where services are rebuilt, the platform provides block and file storage, load balancing and ingress, a private container registry, backup, monitoring, and object storage. For anything outside those categories, the assessment says what becomes of it.
Databases get the same three decisions. On the platform, high-load databases can run directly on the node, with no virtualization layer in the path, and the rest are provisioned self-service.
After the move
The platform build and the move are one engagement, and it ends once the last wave is signed off. Running the platform for you is a separate engagement: the Kubernetes platform engagement, or, on SECO, its own operations package.
What the assessment gives you
The engagement usually starts with a paid, fixed-scope cloud repatriation assessment, which ends in four things, in writing:
- A current-state read. The estate the requirement covers, the managed services it uses, what depends on them, and which of the layers your provider runs for you today would become yours to run.
- A target architecture. What each service becomes, what the destination has to provide, and whether what we build meets it.
- A prioritized plan. The platform build first, then the move itself, in waves, with rough effort. Buying or renting the hardware, preparing the data center, and providing the network link to your provider are yours, and sit outside the plan.
- A recommendation. Our view, written plainly, including “not yet” where that is the honest answer. It also names the cost lines for weighing owning against staying, and leaves the total to you.
If you already have an exit plan, send it; where it leaves gaps, the assessment covers only those.
Why this practice
The work is led by a principal engineer with infrastructure work reaching back to the end of the 2000s, most of it running platforms for other people’s production rather than one in-house estate. At a regional cloud provider and managed-service provider that meant dozens of dedicated Kubernetes clusters, some internal and some on clients’ own premises in regulated sectors, along with the bare metal and distributed storage underneath them: the kind of platform a repatriation lands on. The certifications sit behind that experience, including the full CNCF Kubestronaut set, which only a few thousand engineers worldwide hold. Engagements are principal-led, with senior specialists brought in as the work requires. We work within your access controls and change process, with least-privilege credentials and an auditable trail.
Comparing the cost
Once the hardware is bought, owning the platform gives you a running cost you can forecast; the purchase itself, and every expansion and refresh, is priced by the hardware market on the day you buy. Individual layers may still carry licenses or support on their vendors’ terms, and nothing we put in place prices the whole estate or reprices it on a schedule you do not set. Servers you rent are priced on their host’s terms.
An honest comparison includes these lines: hardware, building the platform, the people who run it, hosting, licensing, the move itself, transfer during the move, the traffic between what moves and what stays, and any commitment you still owe the provider, which bills to the end of its term. A fixed-scope assessment cannot estimate a multi-year total reliably. We size the platform; you price it, and your finance team builds the total from your own numbers, off those lines.
The large providers now credit transfer fees for customers who are leaving, on application and on their own conditions, and only for leaving something entirely: a whole service at some, the whole account at others. Each also wants the application before any data moves, counts only ordinary transfer over the internet, and credits only a limited period. Moving only what the requirement covers usually leaves data in services you keep, so plan to pay for at least part of the transfer; the assessment shows which parts of the move could qualify. The overlap still costs money: the day-to-day traffic while both platforms are live, and the rent until the cloud side is decommissioned.
Provider exit terms were checked on 5 October 2026.
When repatriation is the wrong call
Your provider may offer dedicated or on-premises options; some requirements allow them and some do not. Whether yours does is for you and your counsel to decide; if it does, that is usually the smaller move.
Public cloud still earns its place for spiky, unpredictable work that the requirement does not cover.
Anything else the requirement does not cover can stay where it is, unless it depends so closely on what moves that it has to follow it or be changed.
Owning means the engineering, the supply chain, and the Day-2 discipline are yours, to run or to contract out, which is worth weighing before you move more than the requirement asks.
When the destination is another vendor’s platform product, we do not plan or run that move.
For what stays, the Kubernetes platform engagement extends to a managed Kubernetes cluster in your own cloud account, where the provider keeps the control plane.
And the assessment may come back with “not yet.”
Will we pay egress fees to leave?
For a partial exit, usually yes: the large providers credit transfer fees only for leaving a whole service at some or the whole account at others, on application and on their own conditions. The assessment shows what could qualify; the day-to-day traffic while both platforms are live still costs money.
Will there be downtime?
Yes. Each wave has a planned cutover window, agreed before the wave runs. We scope the window rather than promise there will not be one.
What happens to the managed services and databases we use today?
Each managed service and database gets one of three decisions in the assessment: rebuilt on the platform, kept where the requirement allows, or retired. Where services are rebuilt, the platform provides block and file storage, load balancing and ingress, a private container registry, backup, monitoring, and object storage; for anything outside those categories, the assessment says what becomes of it. On the platform, high-load databases can run directly on the node, with no virtualization layer in the path, and the rest are provisioned self-service.
Do we have to move everything?
No. What the requirement covers moves, and the rest can stay if it still works across the link to what moved, at the latency and the transfer costs that come with it, and without copying the data the requirement covers back into the cloud it left. You decide what the requirement covers, with your counsel where it needs a legal reading; the assessment maps the dependencies and draws the line with you, workload by workload.
Will it cost less than the cloud?
We do not claim it will. Your finance team builds the total from your own numbers, off the cost lines a comparison needs, including any commitment you still owe the provider. Once the hardware is bought, the running cost is one you can forecast.
How long does it take?
That is a property of your estate: the platform to build and test before the first wave, how many systems move and how tightly they depend on each other, the managed services to rebuild, the data to move against the network link, and the cutover windows the business can take. Buying or renting the hardware, preparing the data center, and providing the network link are yours, and sit outside that timeline.
Who runs the platform during the move, and after it?
Your team, or us, from the first cutover on. Running it for you is a separate service, the Kubernetes platform engagement, described on its own page. A platform we built goes into that engagement without a second assessment. On SECO, running it is covered instead by SECO’s own operations package.
We already have a platform in mind. Does that change anything?
It can. Tell us which and why, and the assessment answers whether what we build meets the needs behind that choice. We do not plan or run a move onto another vendor’s platform product.
Leaving public cloud?
Tell us what the requirement says, any date you have to meet, and where the estate is today. A written reply within two business days: our read on your situation, or the questions we need answered before we can give you one. Prefer an NDA first? Say so and we’ll start there.