Cloud migration service

Senior engineers who move you off the hyperscalers, then leave

SaveOps is not a consultancy that delivers a strategy deck and bills a retainer. We place senior engineers inside your existing team, on a day rate (a TJM), to do the migration with your engineers. When the workload runs on EU-sovereign infrastructure and your team owns it, we hand over and leave. The deliverable is a migrated, owned-by-you system and a clean exit. Never a report, never a retained dependency.

How the engagement works

One model, deliberately narrow: embedded engineering hours with a defined handover. Here is what that means in practice.

  • Embedded, not advisory Our engineers join your team, your stand-ups and your repositories. They write the infrastructure-as-code, cut over the databases and debug the 2 a.m. incident alongside your people, not from a slide deck.
  • Billed on a day rate (TJM) You pay a transparent day rate per engineer for the days worked, scoped to the size of your estate. No licence, no retainer, no per-seat platform fee. When the work is done, the billing stops.
  • Insider knowledge of the target The bench includes former engineers from European cloud providers such as Scaleway, so the migration is designed by people who have run the destination in production, not only the source hyperscaler.
  • Radical honesty about gaps Where an EU provider genuinely lags (serverless breadth, managed ML, a global CDN), we say so before you sign and design around it. The AWS-to-EU service map never softens a gap to win the deal.
  • We leave Success is your team operating the workload without us. We do not engineer a retained dependency; the handover (runbooks, infrastructure-as-code, a trained team) is part of the deliverable, not an upsell.

The phases of an embedded migration

Every engagement is scoped to your estate, but the shape is consistent. These run in order, with your team involved at each step so the knowledge stays in-house.

  1. Discovery and inventory We map your live estate (every managed service, data store, network dependency and cost line) against a target EU provider, and grade each workload as a clean move, a partial one or a real gap. No migration starts on a guess.
  2. Target design and proof of concept We choose the EU-sovereign provider (or mix) that fits your workloads, then prove the risky parts first: the database cutover, the object-storage repoint, the one service with no managed twin. Surprises surface here, not in production.
  3. Incremental migration Workloads move in reviewable increments (never a single big-bang cutover), with rollback paths and your engineers driving alongside ours. Data-gravity moves and egress are sequenced to control both risk and cost.
  4. Handover We leave behind infrastructure-as-code, runbooks and a team trained to operate it. The point of handover is that your engineers can run, scale and debug the platform without us on the call.
  5. Clean exit We disengage. The workload is yours, on infrastructure you control, with no SaveOps dependency, licence or lock-in left behind. It is the same reversibility we build for your relationship with the old hyperscaler.

What “done” means

A migration we would put our name on clears every one of these. Otherwise it is not finished.

  • The workload runs in production on EU-sovereign infrastructure, not in a staging environment or a slide.
  • Your team owns and operates it: infrastructure-as-code in your repositories, runbooks written, on-call trained.
  • The old hyperscaler account can be wound down, with no silent dependency left pinning you to it.
  • There is no retained SaveOps dependency: no proprietary tooling, no licence, no “call us to change anything”.
  • Reversibility is intact: you could move again, off this provider, without a rewrite. Sovereignty includes the freedom to leave us too.

How we bill: the day rate

We bill a transparent day rate (a TJM) per embedded engineer, for the days actually worked. The total cost is a function of two things you can reason about: the day rate, and the number of engineer-days your estate needs.

That second number depends on how much of your stack sits on clean rows versus real gaps. A stateless, container-and-Postgres estate is a fraction of the effort of one leaning on DynamoDB, Redshift or deep Lambda event wiring. Our per-provider migration pages give directional engineer-day ranges for a mid-sized estate, and the cost calculator estimates the infrastructure bill after the move.

What we do not do: sell a licence, a platform subscription, a retainer, or a strategy deck. When the migration is done and your team owns it, the billing stops.

What a CTO asks before engaging

Do you take over our infrastructure, or work with our team?
With your team. Our engineers embed in your existing squad (same repositories, same stand-ups) precisely so the knowledge stays with you after we leave. A migration where only SaveOps understands the result has failed our own definition of done.
Which EU provider will you move us to?
Whichever fits your workloads, not whichever we prefer. We grade your estate against the target’s managed catalogue first: a streaming-heavy stack may point to OVHcloud, a cost-driven one to Hetzner, a balanced one to Scaleway. The service map is where that comparison starts.
How do you avoid becoming the new lock-in?
By making the handover the deliverable. Everything is infrastructure-as-code in your repositories, documented in runbooks and operable by your team. We build reversibility away from us with the same rigour we build it away from the hyperscaler.
Can you prove past migrations?
We can describe them anonymised (for example, a fintech that moved its workloads off AWS) and point to the specific EU providers our engineers have run in production. We do not publish client logos or invented case studies; honesty is the product.