Scaleway 5: Migrating from AWS to Scaleway - A Step-by-Step Checklist
A cloud migration is a project, not a single event. Done well, it is methodical, low risk, and mostly invisible to end users. Done badly, it becomes a string of outages and rollbacks. This checklist covers the sequence that tends to work best: audit first, run systems in parallel where the risk justifies it, and only cut over when you are ready.
This is a general sequence for standard web application and data workloads. Your own architecture may need extra steps, so use this as a framework rather than a fixed recipe.
Phase 1: Audit and Inventory
Before touching any infrastructure, document what you have.
- List every AWS service in use: EC2, RDS, S3, EKS, Lambda, CloudWatch, Route 53, and anything else.
- Record the instance types, database engine versions, storage volumes, and region settings for each one.
- Identify all inter-service dependencies, including what talks to what and in which direction.
- List all third-party integrations that rely on AWS-specific endpoints, such as S3 bucket URLs, RDS connection strings, and similar references.
- Review your data classification: what data is stored where, and what retention and compliance requirements apply to each dataset.
- Identify which workloads are stateless, and therefore easier to migrate, and which are stateful and will need proper data migration planning.
The output of this phase is an inventory document. Do not skip it. When migrations fail, it is usually because undocumented dependencies only come to light at cutover.
Phase 2: Scaleway Account Setup
- Create a Scaleway Business account. New Business accounts come with €100 in free credit.
- Set up IAM roles and policies for your team. Scaleway uses a project-based IAM model that is broadly similar to AWS.
- Configure billing alerts. Scaleway can send alerts when spending thresholds you choose are met.
- Enable the regions you plan to use: Paris, Amsterdam, Warsaw, or a mix of them.
- Create a test project that is separate from your production project.
Phase 3: Networking Configuration
- Create a Private Network, which is Scaleway’s equivalent of a VPC, in each region you plan to use.
- Configure Security Groups to control access to your compute resources.
- Set up a Load Balancer if your architecture needs one.
- Configure DNS in Scaleway Domains and DNS by adding your domains and creating the initial record set.
- Do not switch DNS over yet. DNS should be the final step.
Phase 4: Data Migration
This is usually the highest risk phase and the one that needs the most planning.
- For Object Storage: use rclone or the AWS CLI with a Scaleway-compatible endpoint to sync S3 buckets to Scaleway Object Storage. (Scaleway’s endpoint format is s3.fr-par.scw.cloud for Paris, s3.nl-ams.scw.cloud for Amsterdam, and s3.pl-waw.scw.cloud for Warsaw.) Both tools support server side copy for large datasets. Run an initial sync, then a delta sync immediately before cutover.
- For Managed Databases: export from RDS using pg_dump for PostgreSQL or mysqldump for MySQL. Import the data into a Scaleway Managed Database instance. Check row counts and data integrity before moving on.
- For stateful applications: coordinate the data migration with a maintenance window so the source and destination do not drift apart.
- For stateless applications: data migration is not required. Deploy fresh and point the application at the migrated data store.
Phase 5: Application Deployment
- Deploy your application to Scaleway Virtual Instances or Kapsule, depending on your setup, using your existing deployment tooling such as Terraform, Ansible, Helm, or your CI/CD pipelines.
- Update all connection strings and environment variables so they point to Scaleway endpoints, including database hosts and S3 compatible object storage endpoints.
- Run your application against the migrated data in the Scaleway environment. This is your staging verification, so treat it with the same seriousness as production.
- Run your full test suite and fix any issues before moving forward.
Phase 6: Parallel Running
For production workloads where downtime is not acceptable, run both environments in parallel before cutting over.
- Keep the AWS environment live and handling production traffic.
- Run the Scaleway environment in read-only or shadow mode against replicated data.
- Monitor both environments using Scaleway Cockpit and AWS CloudWatch.
- Resolve any performance or behaviour differences before cutover.
Parallel running does add cost, because you are operating two environments at the same time, but it greatly reduces the risk of an emergency rollback. For databases, maintain replication from AWS RDS to Scaleway Managed Database during this phase so the data stays in sync. In most cases, parallel running lasts two to five days. Factor this into your migration budget as a known, bounded cost.
Phase 7: DNS Cutover
- Lower your DNS TTLs to 60 seconds, 24 to 48 hours before the planned cutover. This helps reduce propagation delay.
- At cutover, update your DNS records so they point to the Scaleway IP addresses.
- Monitor traffic in real time. Scaleway Cockpit and your application monitoring should show traffic arriving as expected.
- Keep the AWS environment live for 24 to 48 hours after cutover as a fallback. If something goes wrong, you can revert the DNS.
Phase 8: Decommission
- Once traffic has been stable on Scaleway for 48 to 72 hours, begin terminating your AWS resources.
- Delete S3 buckets, RDS instances, EC2 instances, and Load Balancers.
- Cancel or adjust Reserved Instances in line with AWS’s termination process.
- Update your documentation and runbooks so they reference Scaleway.
The next post looks at compliance considerations for regulated industries.
Ready to Have a Conversation?
If you have read this series and recognised your organisation in it, the next step is simple. Get in touch. We will have a chat, ask a few questions, and give you an honest view of what is involved. No charge. No obligation.
Back to: Migrate from AWS to Stackit Series
