How to choose a cloud exit consultancy for a move to an EU cloud

To choose a cloud exit consultancy for a move from AWS to a European-owned cloud, look for a partner that delivers clean Infrastructure as Code (such as Terraform), uses live database replication rather than dump-and-restore scripts, provides a tested rollback mechanism, and works under a fixed or milestone-based contract after an initial discovery phase. Avoid general IT agencies that only hold US hyperscaler certifications. Your contract should explicitly require an audited resource inventory before execution starts, full ownership of all provisioning code, and strict boundaries around customer data access.

Key takeaways

Separate discovery from execution: Never sign an open-ended time-and-materials contract for the entire migration. Pay for a bounded inventory and architecture phase first, or require a fixed price once read-only discovery is complete.
Understand who you are hiring: Destination cloud providers offer professional services that know their own platform deeply, while independent migration partners help you compare providers, handle multi-provider architectures, and clean up the source AWS environment.
Demand Infrastructure as Code and live sync: A serious partner rebuilds your infrastructure cleanly in Terraform or OpenTofu and uses logical replication for databases.
Put rollback and data rules in the contract: Require a documented cutover runbook with a defined write-pause window, reverse data sync for post-cutover rollback, and a Data Processing Agreement (DPA) that minimizes human access to production data.

What a cloud exit consultancy actually does

Moving off AWS to an EU-owned cloud provider—such as UpCloud, Scaleway, Hetzner, OVHcloud, STACKIT, IONOS, or Exoscale—is a different engineering problem than moving workloads into AWS. When companies move into a US hyperscaler, they often rely on vendor-subsidized migration programs and proprietary migration agents. Moving out requires translating AWS-specific constructs into portable, standard equivalents.

A competent cloud exit partner handles five specific areas of work:

Discovery and service mapping: Auditing your AWS billing exports, IAM roles, networks, and Terraform state to find every active resource, including forgotten snapshots, elastic IPs, and regional data transfer paths. You can preview what this mapping looks like using the free EU Cloud Service Map.
Target architecture and sizing: Translating AWS instance families, security groups, and VPC setups into the destination provider’s networking and compute model. Where an EU cloud lacks a direct managed equivalent (for example, Hetzner does not offer managed databases or managed Kubernetes), the partner must design how those services will run reliably on virtual servers or across a secondary provider.
Infrastructure as Code (IaC) rebuild: Writing clean, modular Terraform or OpenTofu code for the new environment so your team can manage it after the consultancy leaves.
Data synchronization and CI/CD integration: Setting up continuous logical replication for relational databases (PostgreSQL, MySQL), syncing S3 buckets to EU S3-compatible object storage with checksum verification, and helping your engineers point existing deployment pipelines to the new servers.
Cutover, rollback, and AWS decommissioning: Running the switchover during a planned maintenance window, keeping a reverse path open in case of unexpected application issues, and safely tearing down the old AWS accounts so stray bills do not continue.

Independent migration partner vs. destination provider professional services

When you decide to move to a European cloud, you generally have two choices for outside help: the destination cloud provider’s in-house professional services team, or an independent migration partner. Both have clear strengths and trade-offs.

Comparison area	Independent migration partner	Destination provider professional services
Provider selection	Can benchmark multiple EU clouds (e.g., comparing UpCloud vs. OVHcloud vs. Scaleway) against your workload and budget.	Will architect exclusively for their own platform, even if a specific workload fits better elsewhere.
Platform depth	Broad operational knowledge across AWS and several EU clouds; relies on public APIs and standard tooling.	Direct access to internal product teams, roadmaps, and deep platform-specific troubleshooting.
Source cloud (AWS) work	Actively works inside your AWS environment to untangle dependencies, manage exit notices, and shut down old resources.	Usually stops at their own boundary; gives you guidance on how to push data in, but rarely touches your AWS account.
Commercial incentives	Paid for the migration project itself; motivated to finish the cutover and hand over keys on schedule.	Often subsidized or discounted to win your recurring monthly cloud spend; scope is usually limited to onboarding architecture.
Hybrid setups	Comfortable building setups that span providers (e.g., bare metal on one EU provider, managed database on another).	Designs single-cloud architectures.

If you already know which EU provider you want, have an internal DevOps team to handle the AWS teardown, and mainly need architectural validation on the new platform, the destination provider’s solutions architects are often enough. If your engineering team is busy shipping product and you want another team to build the Terraform, wire the database replication, coordinate the cutover, and clean up AWS, look for an independent specialist.

Questions to ask before you sign

When interviewing potential partners, skip generic questions about how long they have been in business. Ask operational questions that reveal how they actually move production systems.

1. “Which target European clouds have you deployed to in the last 12 months?”

Many traditional European IT consultancies advertise “cloud migration” but do 95% of their work moving on-premises VMware servers into AWS or Azure. Ask which specific EU clouds they have automated with Terraform recently. Ask them to name two technical quirks or limitations of the target provider you are considering (for example, how private networking works across availability zones, or how load balancer proxy protocols are configured). If they cannot name specific limitations of the target cloud, they have not used it in production.

2. “How do you move our production database, and what is the expected write pause?”

Listen carefully to the answer. If they propose taking a database dump (pg_dump or mysqldump), copying it over the network, and restoring it on the other side, your application will be offline for hours if your database is more than a few dozen gigabytes. A qualified partner will describe setting up logical replication (or native binlog/WAL replication) over an encrypted tunnel, letting the replica catch up while your application stays live, pausing writes briefly until replication lag drops near zero, and switching connection strings.

3. “How do you handle AWS-proprietary services like SQS, Lambda, or DynamoDB?”

A move from EC2, RDS, and S3 to an EU cloud is mostly infrastructure plumbing. A move involving proprietary AWS services requires application code changes. Ask the partner where they draw the line between infrastructure migration and application refactoring. Do they deploy RabbitMQ, NATS, or Redis to replace SQS? Who updates the application SDK calls—their engineers or yours? Before you even speak to a vendor, you can scan your own repositories with an open-source cloud lock-in scanner to know exactly which proprietary APIs your codebase calls.

4. “What happens two days after cutover if we discover a critical issue?”

Every consultancy has a plan for moving forward; few have a tested plan for moving backward. Once DNS points to the new European cloud and users start writing new rows to the new database, simply switching DNS back to AWS will result in data loss unless those new writes were replicated back to AWS. Ask how they maintain reverse replication after cutover and for how long.

5. “How do you help us avoid AWS data egress fees during the switch?”

Moving terabytes of S3 objects and database snapshots out of AWS generates data transfer fees. Your partner should know how to use the AWS EU Data Act switching mechanisms or standard AWS account closure fee waivers, and how to avoid paying for multiple full-dataset copies during dry runs. You can check your own exposure and download a notice template using the free Cloud Exit Fee Calculator. (Note: under Article 29 of the EU Data Act, Regulation (EU) 2023/2854, switching charges—including data egress fees for switching—are capped at cost until 12 January 2027 and banned entirely from 12 January 2027.)

Pricing models: how migration projects are billed

Consultancies generally price cloud exits in one of four ways. Understanding the incentives behind each model will save you from budget overruns.

Time and Materials (T&M): You pay a daily or hourly rate for engineers. T&M is normal and reasonable when a project requires heavy application refactoring (for example, rewriting hundreds of Lambda functions or migrating off DynamoDB), because neither side can know the exact code complexity upfront. However, for standard infrastructure and database migrations, open-ended T&M shifts all execution risk onto you.
Two-stage (Paid Discovery, then Fixed Price): You pay a small, fixed fee for a 1-to-3 week discovery phase where the consultancy audits your AWS account via read-only access and produces a migration plan, target bill estimate, and fixed price for execution. You should retain the right to walk away with the discovery deliverables if you do not like the execution quote.
Fixed Price / Milestone-based: For standard workloads (VMs, Kubernetes, RDS, S3, load balancers), a mature specialist can inspect your billing export and read-only metadata, and give you a fixed price broken into milestones (e.g., 1. Inventory & Architecture, 2. IaC Environment Built, 3. Data Sync Live, 4. Production Cutover).
Savings-share or Percentage of Spend: Some firms charge a percentage of your annual cloud spend or a percentage of your first year’s savings. Be cautious here: this model can incentivize a partner to push you toward the cheapest possible hardware setup (such as unmanaged bare metal without proper redundancy) just to inflate the theoretical savings figure. To check expected infrastructure savings objectively before entering negotiations, upload your billing export to a browser-based Cloud Bill Analyzer.

Red flags to watch out for

Walk away or pause negotiations if you see any of these behaviors during the sales process:

Promising “zero downtime” without inspecting your database: Any migration that switches the primary database for write operations requires at least a brief pause in writes (even if it is only 15 to 60 seconds) to prevent split-brain data corruption. Anyone promising literal “zero downtime” before auditing your database schema and application connection pooling is either using marketing language or planning an unsafe cutover.
Using proprietary Terraform wrappers you cannot maintain: Some consultancies deploy their own closed-source Terraform modules or custom management agents into your new cloud, then try to sell you a mandatory monthly managed-services retainer to maintain them. Insist on standard, human-readable Terraform or OpenTofu using official provider plugins.
Recommending US-owned “sovereign” regions when you asked for an EU-owned cloud: If your requirement is escaping US jurisdiction (such as the US CLOUD Act) by moving to a European-headquartered provider, watch out for AWS Partners who try to steer you into the AWS European Sovereign Cloud instead. While the AWS European Sovereign Cloud keeps data and operations inside the EU, it remains owned by Amazon, a US corporation.
Asking for full Administrator IAM keys before signing an NDA and DPA: For an initial assessment, a billing export or AWS ReadOnlyAccess / ViewOnlyAccess role is sufficient. A vendor never needs write access during scoping.

What to require in the contract

Once you select a partner, make sure your Statement of Work (SOW) and Master Services Agreement (MSA) cover these four areas explicitly:

1. Audited inventory and scope baseline

Attach the exact inventory of AWS accounts, regions, VPCs, databases, and storage buckets to the contract. Define what happens if a new resource is discovered mid-project, and freeze non-essential architectural changes in AWS during the migration window so neither side is chasing a moving target.

2. Cutover criteria and rollback window

Do not define project completion as “infrastructure deployed.” Define completion as production traffic running on the destination cloud with all agreed health checks passing. Specify:

The maximum acceptable replication lag before the cutover write pause begins (for example, under 5 seconds).
The maximum planned maintenance window duration, after which an automatic abort and rollback to AWS is triggered.
The post-cutover rollback period (typically 14 to 30 days) during which the old AWS environment remains on standby with reverse data synchronization active, before final decommissioning. (If your company is subject to DORA, Regulation (EU) 2022/2554, documenting these exit and fallback procedures also directly supports your regulatory ICT exit strategy requirements.)

3. Data handling, security, and least privilege

Your migration partner will inevitably interact with infrastructure that holds personal or business-critical data. Require:

A GDPR-compliant Data Processing Agreement (DPA) listing any subcontractors.
All data in transit between AWS and the EU cloud to move over encrypted channels (such as WireGuard, IPsec VPN, or TLS 1.3) directly from your AWS account to your new EU cloud account—never staged on the consultancy’s own servers.
Checksum verification logs proving that object storage buckets were copied completely without silent corruption.
A clause requiring immediate revocation of all IAM roles, SSH keys, and VPN access upon project sign-off.

4. Code ownership and handover deliverables

State clearly that all Infrastructure as Code, CI/CD pipeline modifications, runbooks, and architecture diagrams become your company’s intellectual property upon payment (or are licensed under an open, perpetual, royalty-free license without dependency on the vendor). Require a live handover session where your internal engineers run a terraform plan and deploy an application change without the consultancy touching the keyboard.

Frequently asked questions

How long does a migration from AWS to a European cloud usually take?

For a typical 10-to-300 person company running standard infrastructure (virtual machines, Kubernetes, PostgreSQL/MySQL, Redis, and S3 object storage), a well-run migration takes between 3 and 8 weeks from inventory to cutover, followed by a 30-day standby window before shutting down AWS. If the project requires rewriting code to replace proprietary services like DynamoDB or AWS Step Functions, timelines extend based on software engineering capacity.

Always open the destination cloud account directly in your own company’s name, with your own billing details and root credentials. Letting a consultancy resell the cloud infrastructure puts another legal and financial layer between you and your servers, complicates support escalation, and makes it harder to part ways with the consultancy later.

Can we claim AWS egress fee waivers if a consultancy runs our migration?

Yes. Under AWS policy and the AWS EU Data Act Addendum, eligibility for data transfer fee reductions or waivers depends on the customer account and the nature of the workload exit, not on whether your internal staff or a third-party contractor executes the transfer. However, your company (as the account holder) must submit the formal support ticket or switching notice to AWS before moving the bulk data. Always verify the current procedure on the official AWS documentation pages before starting large transfers.

Do we need to rewrite our CI/CD pipelines to switch clouds?

Usually, you only need to update the deployment target step. If you build Docker containers or application artifacts in GitHub Actions or GitLab CI, the build and test steps stay identical. The consultancy should work with your team to update the final deployment step—pointing it to the new container registry, Kubernetes cluster, or virtual servers on the European cloud.

How MoveInfra can help

MoveInfra moves companies’ cloud infrastructure from AWS, Google Cloud, Azure, and DigitalOcean to European-owned clouds (UpCloud by default, as well as Scaleway, Hetzner, OVHcloud, and STACKIT, IONOS, or Exoscale on request) for a fixed price. We analyze your setup via a billing export and read-only access, rebuild your environment cleanly in Terraform, sync your databases and object storage live, update your CI/CD deployment targets with your team, and keep reverse replication running for 30 days after cutover so you always have a safe rollback path. If you want to check your potential savings before talking to anyone, you can test your numbers with our free Cloud Bill Analyzer.

Sources

Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex — Articles 25, 29, and 34 covering cloud switching contracts, notice periods, and the phase-out of switching and data egress charges.
Regulation (EU) 2022/2554 (Digital Operational Resilience Act / DORA) on EUR-Lex — Requirements for ICT risk management and documented cloud exit strategies.
AWS EC2 On-Demand & Data Transfer Pricing — Official AWS documentation detailing data transfer out rates and the process for requesting fee waivers when exiting AWS.