Cloud-to-cloud migration: from a hyperscaler to EU infrastructure
Your workloads are already in the cloud. The first move happened years ago, and it went fine. Since then, the monthly bill has crept up, every new managed service has tied you a little closer to one provider, and someone in legal has started asking where your data actually sits and who can get at it.
That last question is usually what puts a cloud-to-cloud migration on the roadmap. And it’s a different job from the first move. Copying the data is the easy part. Untangling the services you now depend on is what takes the time.
This article covers what migrating between providers involves, why European organisations are looking at EU infrastructure, what the new rules change, and a process you can follow. If you’re still shaping the bigger picture, start with our cloud migration strategy.
What is cloud-to-cloud migration?
Cloud-to-cloud migration means moving applications, data, and services from one cloud provider to another, or from one cloud environment to another, without passing back through on-premise infrastructure.
It tends to take one of four forms:
- Public to public: from a hyperscaler to another public cloud, such as a European one.
- Public to private: onto dedicated infrastructure you control more tightly.
- Single provider to multi-cloud: spreading workloads so no one provider holds everything.
- SaaS to SaaS: moving files, email, or collaboration data from one tool to another.
It’s also not the same as an on-premise project. There’s no hardware to retire, which sounds easier. But you’re inheriting years of cloud-native features, contracts and data gravity, and that makes leaving harder than the architecture diagram suggests. Most of the work sits in the dependencies, not the servers.
Why European organisations move away from hyperscalers
Four reasons come up most often.
- Cost. Managed services make it easy to start, but the bill grows with usage. Moving steady, predictable workloads to infrastructure priced for them is one of the most direct ways to cut costs. The savings aren’t automatic, though. They depend on how well you design the target.
- Vendor lock-in. The deeper you go into proprietary services, the more re-architecting and rewriting it takes to leave. Plenty of teams only discover this when they try.
- Control. European organisations increasingly care about who controls the company running the platform, not just where the data lives. More on that in a moment.
- Regulatory compliance. GDPR, sector rules and client contracts all set requirements for handling sensitive data, and those requirements now often cover jurisdiction as well as location.
The shift shows up in the numbers. Gartner forecasts that European spending on sovereign cloud infrastructure will grow from $6.9 billion in 2025 to $12.6 billion in 2026. It also expects around 20% of current workloads to move from global to local providers.
Hyperscalers do offer global reach and a huge catalogue of services, which helps when you need to move fast. If your business depends on both, a full exit may not make sense. Moving the regulated or cost-heavy part of your estate first is often the better starting point.
Data residency isn’t data sovereignty
Data residency is where your data is physically stored. Data sovereignty is whose laws apply to it, and who controls the provider storing it.
People mix these up all the time. Data in an EU data centre can still fall under non-EU jurisdiction if a non-EU parent company owns or controls the provider. The best-known example is the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act), which lets US authorities request data from US-controlled providers wherever their data centres are. A region label in a console doesn’t change who owns the company.
Before you pick a provider, ask three questions:
- Who owns and controls the provider, and under which law?
- Who can access your data and encryption keys, and on what legal basis?
- Could you move your platform and data elsewhere without rebuilding?
If the answers are vague, so is the sovereignty. Encryption helps, but it doesn’t settle the jurisdiction question.
What the EU Data Act changes for your exit costs
For years, one of the best reasons to stay put was the price of leaving. Pulling data out of a hyperscaler meant paying for every terabyte, on top of the engineering work.
The EU Data Act changes this. Its switching rules have applied since 12 September 2025. Until 12 January 2027, providers can only charge reduced switching fees, capped at what the switch actually costs them. After that date, switching charges are banned, including fees for the data transfer the switch requires.
It isn’t a blanket ban on egress fees, though. Moving data during normal operations can still be charged. So can running services in parallel across providers in a multi-cloud set-up, although only at cost.
So leaving is cheaper than it used to be. The planning, the engineering and the time are still on you.
Find the right path to cloud independence
Learn more
DORA, NIS2 and the exit plan you need anyway
In a regulated sector, an exit plan may not be optional.
DORA (the Digital Operational Resilience Act) has applied to EU financial entities since 17 January 2025. It requires exit strategies for ICT third-party services that support critical or important functions. For many banks, insurers and payment firms, a documented and tested cloud exit strategy is now a compliance requirement.
NIS2 (the revised Network and Information Security Directive) brings supply chain security into scope for essential and important entities. You need to know where your workloads run, who operates them, and what happens if a supplier relationship ends.
Both point the same way, and an exit plan pays off beyond compliance too. It’s good business continuity and disaster recovery.
The other half of the job is not rebuilding the same trap on the new platform. A few habits keep you portable:
- Build on open standards like Kubernetes, S3-compatible storage APIs, and OpenID Connect (OIDC) for identity.
- Keep your platform configuration in Git, so you can rebuild it anywhere.
- Own your platform rather than licensing it, and check that the security features you rely on aren’t tied to one vendor.
- Write down your exit before you sign, not after.
Map your managed services before you move
In a cloud-to-cloud migration, most of the effort goes into replacing services, not moving virtual machines. European cloud platforms offer solid infrastructure, but often fewer ready-made managed services, so it pays to know the gaps before you commit.
Start by listing what your current environment actually uses. Then map each item to a portable equivalent:
| What you use today | Portable equivalent | Watch for |
| Managed Kubernetes or containers | Upstream Kubernetes | Provider-specific add-ons |
| Managed relational database | PostgreSQL run by an operator, with high availability and backups | Maintenance effort vs managed-service cost |
| Object storage | S3-compatible object storage | API edge cases in older code |
| Secrets and keys | Open-source secrets manager with OIDC | Key migration and rotation |
| Monitoring and logs | Open observability stack (metrics, logs, traces) | Dashboards and alerts to rebuild |
| Identity | Single sign-on via OIDC with your existing identity provider | Role mapping |
| Serverless functions and proprietary APIs | Containers, or a redesign | Where rewriting is unavoidable |
Most categories have a mature open-source answer. Serverless functions and proprietary APIs are where re-architecting is most likely, so flag them early and budget for them. Any cloud-native features you lean on today belong on the map as well, even if the honest answer is “we’ll redesign this”.
Tooling can speed this up. NoviArc’s AI-assisted discovery scans your environment, maps each managed service to an open equivalent, and flags the gaps before you commit to a plan. A Spyrosoft architect reviews every recommendation, so you know what can move as it is and what needs more work. You end up with a target design that has security baselines in place from the start.
The cloud-to-cloud migration process in six steps
Every migration is a bit different, but the steps are broadly the same. They assume you’ve already agreed on your wider migration strategy.
1. Assess what you have and choose the right cloud provider
List your workloads, dependencies, data classes, and current spend. Then compare providers on ownership and jurisdiction, certifications, regions and pricing, and on whether they or their partners offer ongoing support. Start from what the business needs and shortlist from there.
2. Decide what happens to each workload
Use the service map to decide, workload by workload, what moves as it is, what gets replatformed, and what gets rebuilt. Not everything has to move at once, and some workloads may not need to move at all.
3. Build the target platform first
Set up identity, networking, security baselines, observability, and backups before any data moves. The platform should be ready for production before the first workload arrives, not after the first incident. Security is much easier to design in than to retrofit.
4. Run a pilot migration
Pick a non-critical workload and move it end to end. Measure performance, cost, and effort, then compare them with your estimates. A pilot is the cheapest way to find out where the plan is wrong, and to see whether you can improve performance rather than just match it.
5. Migrate data and verify its integrity
Plan the data migration in waves, with transfer windows that suit your bandwidth and a rollback point for each wave. Expect a period of dual running. After each transfer, check integrity with checksums and record counts, so any data loss shows up in testing rather than in production.
Files and SaaS data. Files, shares and SaaS stores are easy to forget. Teams keep documents in Google Drive, shared folders and local storage, often with years of permissions attached. When you migrate files, bring permissions and version history with them, and decide what stays local. Moving unstructured data takes a long time, so start early and run it alongside the workload waves.
6. Cut over, then fine-tune
Switch traffic in stages, for example through DNS, and keep the old environment on standby until you’re confident. Then decommission it and close the old accounts so you stop paying twice. After that, right-size workloads, tune autoscaling, and review costs. Gains in performance and scalability usually come from this tuning, not from cutover day itself.
Common problems and how to avoid them
A handful of problems turn up in almost every move between providers:
- Skills. Your team knows one cloud’s tooling and naming. Pair engineers with people who’ve done this before, and start training early.
- Dual running. For a while you’ll pay for both environments. A short, phased migration keeps that window small.
- Hidden dependencies. Services that call each other across accounts or regions can break in ways nobody documented. Map them before you migrate anything.
- Downtime. Protect your customers with small waves, agreed cutover windows, and a tested rollback.
In short, small verified waves usually beat one big cutover.
Move to EU infrastructure with a platform you own
A migration goes faster when the platform is ready before the first workload arrives. NoviArc (Spyrosoft Cloud Foundry) is built for that.
NoviArc gives you a production-ready platform built on upstream, open-source Kubernetes and running on the European infrastructure you choose, in weeks rather than months. Spyrosoft helps you pick the infrastructure provider and builds the platform on top. Nothing is licensed back to you, so the platform is yours and moves with you if you leave. After go-live, you can run it yourself, get your team trained, or keep Spyrosoft on for managed services.
Schedule a 30-minute consultation with a Spyrosoft architect to review your workloads and assess the total cost of ownership (TCO). During the session, we’ll discuss how your existing services would map to the target environment and what the migration would require.
FAQ
It’s moving applications, data, and services from one cloud provider to another without going back to on-premise hardware. That could mean switching between public clouds, moving from public to private cloud, spreading workloads across several clouds, or migrating between SaaS tools.
The main reasons are cost, lock-in, control, and regulation. Steady workloads can cost less on infrastructure priced for them, open standards make later moves easier, and an EU-controlled provider reduces your exposure to non-EU law. Regulated sectors also face growing exit and supply chain requirements.
Not automatically, because location and control are different things. If a provider’s parent company is outside the EU, laws such as the US CLOUD Act may still give foreign authorities a route to your data. Check ownership, key control, and legal jurisdiction, not just the region.
Partly. From 12 January 2027, providers can’t charge switching fees, including egress for the switch itself. Until then, switching fees must be reduced and cost-based. Egress during normal operations can still be charged, so check your contract before you plan around zero transfer costs.
It depends mostly on how many managed services you need to replace. Building the target platform is fairly predictable. Moving workloads varies with their dependencies, data volumes, and how much redesign they need. A pilot gives you the most reliable estimate for the rest.
Usually not, if they already run in containers. Applications built on proprietary managed services, serverless functions, or provider-specific APIs often need some rework. Mapping your services first shows where code changes are unavoidable and where a portable equivalent will do.
Use open standards such as Kubernetes, S3-compatible storage, and OIDC, keep your configuration in Git, and make sure you own the platform outright. Document how you would leave before you sign, and test that plan, so a later move doesn’t turn into a big project.
Yes, and many organisations do. You might keep workloads that need global reach with a hyperscaler and move regulated or cost-heavy ones to EU infrastructure. Plan for the extra complexity, though, including networking, identity, and egress between providers.
arrow_circle_rightCONTACT US
Build a cloud platform that gives you more control
Marcin Waleczko
Vice President of Client Services
arrow_circle_right OUR ARTICLES
