Denys Zaruin

Posted on Nov 4 Originally published at moveinfra.eu

What happens on switch day: cloud migration cutover explained

#cloud #cloudmigration #cutover #dns

Originally published on moveinfra.eu.

A cloud migration cutover is the final phase of moving infrastructure from one cloud provider to another, where live user traffic and database writes are switched from the old environment to the new one. For most European small and mid-sized companies, a well-planned cutover takes between five and thirty minutes of planned maintenance. During this short window, your engineering team pauses new data writes on the old cloud, waits a few seconds for the new database to finish syncing, updates the Domain Name System (DNS) records to point to the new servers, and verifies that the application works properly before reopening traffic to users.

Key takeaways

Cutover is the final step, not the whole migration: Building servers, configuring networks, and copying bulk data happen weeks before switch day.
Brief write pauses beat complex active-active setups: Accepting a few minutes of read-only mode or a maintenance page is much safer and cheaper than trying to write to two different clouds at the same time.
Preparation controls the clock: Lowering DNS Time-to-Live (TTL) values days in advance and keeping databases in live sync reduces actual cutover time to minutes.
Always keep an exit path: Reverse database replication back to the old cloud lets you undo the switch without losing new customer data if an unexpected bug appears days later.

What is a cloud migration cutover?

When companies talk about moving from a US hyperscaler like AWS or Google Cloud to a European cloud provider, they often picture a massive weekend project where files are copied over while the system is offline. In modern cloud operations, the bulk work happens quietly in the background weeks before anyone touches live traffic.

You build the new virtual machines, Kubernetes clusters, load balancers, and firewalls using infrastructure-as-code tools like Terraform. You deploy your application code to the new servers through your regular deployment pipelines. You also set up a continuous data link so your new database and object storage buckets mirror everything happening in your old environment in real time.

The cutover is simply the moment you change which environment is in charge. Before the cutover, your old cloud is primary (handling live users) and your new cloud is a warm standby. After the cutover, your new cloud is primary, and your old cloud becomes the fallback.

Why a short write pause is the safest approach

Vendors often market the idea of switching clouds with no interruption at all. While technically possible for some architectures, achieving uninterrupted writes across two different cloud providers requires an "active-active" database setup. This means both the old database (for example, on AWS RDS) and the new database (for example, on UpCloud or Scaleway) accept new customer data at the exact same moment.

If two customers update the same record on different clouds within the same millisecond, you get a data conflict. Resolving these conflicts requires complex application changes, custom database routing, and expensive engineering time. For a company of 10 to 300 people, this complexity introduces far more risk than it removes.

A planned write pause is the practical alternative. You schedule the cutover during your lowest traffic window, such as Tuesday at 03:00 CET. You put your application into maintenance mode or read-only mode for a few minutes. Because no new data is entering the old database, the new database catches up completely within seconds. You then promote the new database to be the single source of truth and reopen the application on the new cloud. Your data remains completely consistent, and the engineering effort stays manageable.

What happens before switch day

A calm cutover depends on three preparation steps completed at least 48 to 72 hours before the switch.

1. Lowering DNS TTLs

The Domain Name System (DNS) is the phonebook of the internet, translating your domain (like app.example.eu) into the IP address of your load balancer. Every DNS record has a Time-to-Live (TTL) setting, measured in seconds, which tells internet service providers how long to cache that IP address before checking for an update.

Many domains have a default TTL of 3,600 seconds (one hour) or even 86,400 seconds (24 hours). If you change your DNS record while the TTL is set to 24 hours, some users will still be sent to your old cloud a full day later. Several days before the cutover, you lower the TTL on all relevant records to 60 or 300 seconds. That way, when you change the IP address on switch day, the rest of the internet notices the change within a few minutes.

2. Live data synchronization

Instead of taking a static backup on cutover night and waiting hours for it to restore, teams use logical replication for databases like PostgreSQL and MySQL. Logical replication copies the initial dataset and then streams every new insert, update, and delete from the old cloud to the new cloud as it happens. The time difference between the two databases is called replication lag. Under normal conditions, this lag is less than a second.

For object storage (like moving from Amazon S3 to an S3-compatible bucket on Hetzner or OVHcloud), you run an initial sync days in advance using tools that verify file integrity with cryptographic checksums. On cutover night, you only need to sync the small batch of files created in the final few minutes.

3. Dry runs and synthetic testing

Before moving real users, your team tests the new environment privately. By overriding local DNS settings on their own computers (using the /etc/hosts file) or using internal test domains, engineers can browse the application on the new cloud, verify SSL certificates, check firewall rules, and confirm that background worker queues and caches (such as Redis) respond as expected.

Step-by-step: the cutover timeline

Below is what a typical 30-minute cutover window looks like for a standard web application using a relational database, object storage, and a load balancer.

Time	Phase	Action	System State
T-15 min	Pre-flight check	Verify new environment health, check SSL certificates, and confirm database replication lag is under 5 seconds.	Live on old cloud
T-0 min	Pause writes	Enable maintenance page or read-only mode on the application. Stop background job processors (cron jobs, queue workers) on the old cloud.	Maintenance mode
T+2 min	Drain & sync	Wait for in-flight database transactions to finish. Confirm replication lag reaches zero and run a final delta sync on object storage.	Maintenance mode
T+5 min	Promote target	Stop replication. Promote the new EU cloud database from read-only replica to primary (read-write).	Maintenance mode
T+7 min	Start services	Enable background job processors on the new cloud. Start reverse replication from the new database back to the old database (if using a warm rollback setup).	Maintenance mode
T+10 min	Switch traffic	Update DNS records (A, AAAA, or CNAME) to point to the new cloud's load balancer IP. Disable the maintenance page on the new cloud.	Live on new cloud
T+15 min	Verify & monitor	Run automated smoke tests (login, checkout, API writes). Monitor error logs, CPU usage, and database connections as DNS change propagates.	Live on new cloud

A closer look at the critical steps

Stopping background workers (T-0 min): Web traffic is not the only thing that writes to your database. Scheduled cron jobs, billing scripts, and message queues also change data. If you block web users at the load balancer but forget to pause a background billing worker on the old cloud, that worker might create an invoice on the old database after you have already switched to the new one. Stopping all background processes is mandatory before promoting the new database.

Checking replication lag (T+2 min): Once writes are stopped on the old cloud, engineers check the database metrics to verify that the new database has processed the final bytes of the replication stream. Because the databases were already in sync, this usually takes less than five seconds.

Handling stubborn DNS caches (T+10 min): Even if you set your DNS TTL to 60 seconds, a small percentage of corporate networks and mobile carriers ignore TTL rules and cache records longer. Because you kept the old environment in maintenance mode (or closed its database ports), any user whose network sends them to the old IP address simply sees the maintenance page until their local DNS cache refreshes, rather than accidentally writing data to the old database. Alternatively, some teams configure the old load balancer to proxy traffic directly to the new load balancer during the transition period.

What can go wrong (and how to handle it)

Even with thorough testing, production traffic behaves differently than test traffic. Here are the most common hiccups during a cutover and how operations teams resolve them:

Third-party IP allowlists: If your application connects to external partners—such as payment gateways, bank APIs, or enterprise customer servers—those partners might block requests coming from your new cloud's outbound IP addresses. Prevention: Audit outbound integrations beforehand and give partners your new static NAT gateway IPs a week early.
Email delivery blocks: Sending transactional emails directly from new cloud servers often triggers spam filters because the new IP addresses have no sending reputation. If you are replacing a cloud-native email service like AWS SES, configure and verify domain records (SPF, DKIM, DMARC) with a dedicated email provider well before cutover night.
Hidden hardcoded configurations: Occasionally, an environment variable or configuration file still points to an old internal IP address or proprietary cloud endpoint. Having your CI/CD pipeline ready during the cutover window allows your team to push a quick configuration fix in minutes.

Rollback: keeping your safety net

For European companies—especially those subject to financial regulations like DORA (Regulation (EU) 2022/2554), which requires tested ICT exit strategies and safe transitions—having a reliable rollback plan is essential.

Before you promote the new database (Step T+5 in the table above), rolling back is trivial: you simply turn off the maintenance page on the old cloud and cancel the window.

Once you promote the new database and users start saving new data on the new cloud, rolling back requires more care. If you simply point DNS back to the old cloud three hours later, you would lose all orders, messages, or account changes made during those three hours.

To prevent this, mature migration plans set up reverse replication during the cutover. Once the new EU database becomes the primary, the old cloud database is reconfigured to act as a follower, receiving a live stream of all new changes happening on the EU cloud. If a severe issue appears two days after the cutover, you can repeat a mini-cutover in reverse—pausing writes, letting the old cloud catch up, and switching DNS back—without losing a single row of customer data.

We recommend keeping the old environment running in this reverse-synced state for up to 30 days. Under the EU Data Act (Regulation (EU) 2023/2854), cloud providers may charge no more than their direct cost for switching-related data egress until 12 January 2027, after which switching egress fees are banned entirely across the EU. Once your team is completely confident in the new environment, you sever the replication link and delete the old cloud resources.

Frequently asked questions

How long does a cloud migration cutover take?

For most small and mid-sized architectures where databases and storage are synced in advance, the cutover window takes between 5 and 30 minutes. The actual pause in database writes often lasts less than five minutes; the remaining time is spent running health checks and waiting for DNS changes to propagate.

Can we do a cutover during business hours?

You can, especially if your system uses a load balancer proxy method to forward old traffic, or if your application can run in read-only mode without bothering users. However, most companies prefer to schedule the cutover during their quietest night or weekend hours so engineers can work without pressure and fewer users see the brief maintenance window.

What happens to active user sessions during the switch?

If your application stores user login sessions inside a database or a Redis cache that is replicated to the new cloud, users will stay logged in after the switch. If sessions are stored only in the local memory of the old servers, or if you start with a fresh Redis cache on the new cloud, active users will need to log in again once traffic moves over.

When should we shut down the old cloud servers?

Do not delete your old servers immediately after the cutover succeeds. Keep the old infrastructure running for at least one to four weeks while monitoring performance and monthly billing on the new provider. Once all weekly or monthly background jobs have run at least once on the new cloud without issues, you can safely decommission the old account.

Sources

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

DEV Community