Cut traffic over

Cut over only after the migration rehearsal and target verification pass.

Lower DNS TTL before the migration

For externally managed DNS, lower the TTL of the production traffic record far enough in advance for the previous TTL to expire before cutover. Don’t lower TTL on the day of cutover and assume recursive resolvers immediately honor the new value.

For delegated DNS, plan the registrar nameserver change separately. Existing delegation and DS records can remain cached beyond an individual host record’s TTL.

Record the old and new TTLs, current traffic values, nameservers, and any DNSSEC settings in the migration checklist.

Freeze source changes

Place the source App in maintenance or read-only mode. Pause scheduled jobs, background consumers, administrative edits, and automated imports that can change production data.

Record the freeze time. Changes accepted by the source after the final copy starts may not reach the target.

Perform the final copy

1. Create a final source backup.
2. Repeat the full database export and import, or use a rehearsed incremental method only when the source supports it and the target hasn’t accepted independent writes.
3. Copy new and changed media.
4. Rebuild required caches or search indexes.
5. Repeat the critical data comparisons.

If the final copy or verification fails, keep traffic on the source and restore normal source operation.

Add production domains

Use Manage domains to attach the production hostnames to the target App.

• For delegated DNS, add the domain, stage required records, and change nameservers only when the target is ready.
• For external DNS, add the domain before changing traffic so the portal can display the exact CNAME or A records and begin verification.

Update DNS using the values shown in the portal. Don’t delete the source environment while old DNS answers may still be cached. Don’t remove source certificate coverage or source routing during the rollback window.

Verify live traffic

Test the production hostname from more than one network and device. Confirm:

• the certificate is valid;
• redirects stay on the expected hostname;
• new writes appear only on the target;
• email, payments, webhooks, and external integrations work;
• scheduled jobs and background processing resume;
• error rate and resource usage remain normal.

Create a new record after cutover and confirm it exists only on the target. This detects clients or workers still writing to the source.

Define the rollback boundary

Before accepting target writes, decide who can call rollback and what evidence triggers it. DNS rollback is safe only while the source still contains the authoritative data.

Caution

Once the target accepts customer writes, returning traffic to the source can discard or fork those writes. At that point, rollback requires a tested data-reconciliation plan, not only a DNS change.

Keep the source frozen and unchanged until the team explicitly crosses this boundary or the rollback window ends.

Complete or roll back

Complete the cutover when DNS has converged and the production checks pass. Keep the source protected and unchanged for the agreed rollback window.

Roll back by restoring the source’s write capability and returning DNS to the source only if the source still contains the authoritative data. Don’t direct traffic back to a stale source after accepting production writes on the target without a tested data-reconciliation plan.

After completion, raise TTLs to the intended steady-state values. Retain the source until old DNS answers, customer caches, and integration retries are no longer expected to reach it.

Record the final result in the migration readiness checklist.