A move to Scaleway rarely fails because of Kubernetes – it fails because of everything around it: networking, databases, buckets, DNS, certificates. Clusterward builds the new environment securely, brings data over from AWS, Azure or Google Cloud and moves your hosts one at a time – the old environment keeps running until everything is green.
A move to Scaleway with Clusterward means the target environment is created in your own Scaleway project – a Kapsule cluster in a Private Network, nodes without public IPs, a Managed Database reachable only privately, your own Container Registry. Then you move application by application: connect the image or Git repository, import the data, switch the host. Clusterward manages only the new side; EKS, AKS or GKE stay untouched until you shut them down yourself.
Clusterward creates the cluster, Private Network, gateway and registry in your Scaleway project.
Connect a Git repository, a ready-made image or a Helm chart and roll it out alongside the old environment.
Import the database and buckets while the apps on the target are paused.
Point the host at Scaleway; the certificate follows automatically. Next application.
The parts that otherwise cost weeks in a cloud migration are a form in the cockpit.
The new cluster starts in a Private Network, with nodes without public IPs and the API server reachable only from your address ranges. No hardening after the move.
Schema and data from RDS, Azure Database or Cloud SQL into a Managed Database. The import runs in the cluster; the affected apps pause and start again afterward.
Copy objects from an S3-compatible bucket into a Scaleway bucket, with a progress indicator. Copy and overwrite, never delete – a second run is safe.
Every cluster gets a private registry in your own project. Images are built in the cluster or with GitHub Actions and rolled out from your registry.
Environment variables and secrets per service, optionally in Scaleway Secret Manager. Secrets that already live there are adopted instead of being created again.
Every host gets ingress and a certificate. If the zone is on Cloudflare, Clusterward sets the record itself – it adopts an existing one and switches it instead of creating a second one; otherwise you switch one record.
Most building blocks have a direct counterpart at Scaleway, which Clusterward manages.
| Today | At Scaleway | With Clusterward |
|---|---|---|
| EKS, AKS, GKE | Kapsule | Creation, node pools, upgrades |
| RDS, Azure Database, Cloud SQL | Managed Database | Instance, databases, import |
| S3, S3-compatible buckets | Object Storage | Buckets, keys, copy |
| ECR, ACR, Artifact Registry | Container Registry | Namespace per cluster |
| Secrets Manager, Key Vault | Secret Manager | Secrets per service |
| Route 53, Azure DNS, Cloud DNS | Cloudflare (recommended) | Records and certificates |
How the target environment is created and which permissions the Scaleway key needs is covered under Cluster provisioning. The database import and its prerequisites are described in Managed databases.
Why data should live in EU data centers of a European provider is explained in Digital sovereignty. If you are coming from a Kubernetes platform rather than straight from a hyperscaler, read Migrating from Qovery.
The route service by service, with every pitfall, is described in the article From AWS to Scaleway: what becomes of RDS, S3 and Route 53.
Kapsule clusters secure by default, with Private Network and gateway.
Go to Cluster provisioningPostgres and MySQL connected privately, one database per service.
Go to Managed databasesClusters, databases and buckets in EU data centers.
Go to Digital sovereigntyCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionWe create a cluster, import a sample database and move a host – and estimate with you how long your move will take.
