Migrate from Google Cloud to OVHcloud
To migrate from Google Cloud to OVHcloud, rebuild your infrastructure on OVHcloud in parallel, keep the data in sync, and switch DNS when replication lag is under 5 seconds. Compute Engine, Cloud SQL, Cloud Storage, Cloud Load Balancing, VPC, GKE and Memorystore move automatically. Pub/Sub, Cloud Functions and Cloud DNS need a replacement we help you build. Google Cloud keeps running until you close it.
- What we need first
- A Cloud Billing report CSV export. No account access.
- Access for the scan
- A service account with the Viewer role, or Cloud Asset Viewer for the inventory. Revocable any time.
- Automation
- Expert-assisted: same steps and safety, with more engineer time on the Google Cloud conversion.
How a move from Google Cloud to OVHcloud works
- 1Read-only
Analyze
Upload your Google Cloud bill, then give read-only access. We list everything you run and how it connects. You get a fixed price, the new monthly cost on OVHcloud, and what moves automatically.
You: Upload a file, create a read-only role
- 2Your approval
Copy the environment
We rebuild your infrastructure on OVHcloud as it is today, for example an OVHcloud Public Cloud Instance for every Compute Engine VM: same sizes, networks, firewall rules and load balancers. Your apps are not copied here, only the place they run.
You: Approve the plan and cost
- 3One setting
Move the data
We copy your databases and keep them in live sync, and clone your file storage with checksums. Prefer to do it yourself? You get a step-by-step guide.
You: Allow database replication
- 4Your team
Point your deployments
Together with your team we update your CI/CD pipeline so it deploys the same apps to OVHcloud. Your team tests them on a private address. Your code stays in your repositories.
You: Review the change, test the app
- 5You pick the time
Switch
When data is in sync and checks pass, we point your domain to OVHcloud. Expect a short planned pause for writes, agreed with you.
You: Pick the time
- 6Rollback
Stay safe, then clean up
Your old cloud stays current through reverse sync, so you can switch back. When you are happy, we help you shut it down.
You: Say when to close the old one
Google Cloud services and their OVHcloud equivalents
Automatic means we rebuild and sync it. Assisted means it needs a replacement we help you build. Not yet means we do not offer it today.
| On Google Cloud | On OVHcloud | How it moves | Status |
|---|---|---|---|
| Compute Engine | Public Cloud Instances | Terraform, size-matched | Automatic |
| Cloud SQL | Managed Databases for PostgreSQL / MySQL | Logical replication, then cutover | Automatic |
| Cloud Storage | Object Storage (S3 API) | rclone mirror with checksums | Automatic |
| Cloud Load Balancing | Public Cloud Load Balancer | Terraform | Automatic |
| VPC, firewall rules | vRack private networks, security groups | Terraform | Automatic |
| GKE | Managed Kubernetes Service | Terraform + Velero | Automatic |
| Memorystore | Managed Databases for Caching | Fresh cache or snapshot restore | Automatic |
| Pub/Sub | Managed Kafka or RabbitMQ on servers | Rebuild, we help | Assisted |
| Cloud Functions, Cloud Run | Containers on Kubernetes | Repackage, we help | Assisted |
| Cloud DNS | OVHcloud DNS | Zone export and import | Assisted |
| Firestore, Bigtable | No direct equivalent | Redesign needed | Not yet |
| BigQuery | No direct equivalent | Out of scope today | Not yet |
Who OVHcloud is
OVHcloud is a cloud provider headquartered in Roubaix, France, with data centres across Europe. Its Public Cloud offers Instances, Managed Kubernetes Service, Managed Databases for PostgreSQL, MySQL, caching and Kafka, S3-compatible Object Storage and Load Balancers.
Before you move from Google Cloud
Will moving to an EU cloud break production?
Not if the move is parallel. Your current cloud keeps serving users while the EU copy is built and synced. The switch itself usually needs a short read-only window of minutes, which we schedule with you. If anything looks wrong after the switch, DNS goes back to your old cloud.
Do we need to give you access to our AWS account?
Not for the first step. The free bill analysis only needs a cost export file. For the migration itself you give read-only access: on AWS a role with the managed ViewOnlyAccess policy and an external ID, on Google Cloud the Viewer role, on Azure the Reader role, on DigitalOcean a read-only token. You can revoke it at any time and our access ends.
Do we change anything on our current cloud?
One thing, and you apply it. Database replication needs logical replication enabled on your database, which on RDS is a parameter change and a reboot in your maintenance window. Everything else on the source stays as it is.
How long does a migration take?
It depends on data volume and on how many items need a manual replacement. The bill analysis takes minutes. Building and syncing a typical setup of servers, a managed database and buckets is measured in days, mostly waiting for data to copy. We give you a plan with dates before you commit.
What cannot be moved automatically?
Services without a direct EU equivalent. SQS, SNS and Lambda need a replacement that we help you build. DynamoDB and Redshift need a redesign, which we do not offer today. Every analysis lists these items for your own setup before you pay anything.
Does the EU Data Act ban cloud egress and switching fees?
Yes, for switching. Under Article 29 of the EU Data Act, providers may charge at most their direct costs for switching until 12 January 2027. From 12 January 2027 they may not charge switching fees at all, including data egress for the move. Egress for ongoing parallel use can still be charged.
What does MoveInfra cost?
The bill analysis is free. The exit plan is a fixed price, and a migration is a fixed quote based on what your analysis finds. We do not bill by the hour.