← Back

Migrate from Route 53 to aigw, zero downtime

Five steps. Takes about a day end-to-end (most of which is just waiting for TTLs to expire). Zero dropped queries if you follow the order.

Why the order matters

DNS migration risk is not "data loss", it's that resolvers around the world cache your zone's NS records for the NS TTL (typically 2 days at Route 53). If you cut over before getting that TTL down, half the internet will keep asking Route 53 for answers for up to 48 hours after you stop publishing them there.

The trick is: lower the NS TTL first, wait it out, build the parallel zone in aigw so both providers return identical answers during the overlap window, then flip the registrar delegation. After that, the old Route 53 zone is just dead weight and you can delete it.

Step 1: Lower your NS TTL at Route 53 (T-2 days)

Two days before you want to cut over, lower the NS record TTL on your existing Route 53 hosted zone to 300 seconds. This shortens the "we still believe Route 53 is authoritative" window after the actual switch.

In the Route 53 console: Hosted Zones → your zone → click the NS record (the apex one, not a subdomain) → Edit → change TTL from 172800 to 300 → Save.

Why two days: resolvers that cached the old 48-hour TTL will keep believing it until those caches naturally expire. There's no API to flush every resolver on the internet; you just wait. Once two days pass, any future cache hit gets the new short TTL.

Step 2: Create the parallel zone in aigw (T-2 days, in parallel)

While the TTL countdown is running, build out the zone in aigw to match what Route 53 currently serves. You can do this any time during the wait, nothing is live until you change registrar NS records in step 4.

Sign in to console.aigw.app, click New zone, type your domain.
Export your records from Route 53 (Hosted Zones → your zone → Export to CSV).
Re-create each record in aigw with the same value and TTL. Skip the apex NS records, aigw auto-creates those pointing at ns1.aigw.app and ns2.aigw.app.
Click Test query on a few records to confirm the aigw engine returns the right answer. The widget shows exactly what a resolver would see.

Important: aigw isn't actually serving these answers to the internet yet, your registrar still points at Route 53. Only direct queries to ns1.aigw.app hit the new zone. This is good: you can test as much as you want without affecting production.

Step 3: Verify both providers agree (T-0 morning)

Two days have passed since you lowered NS TTL. Before flipping the delegation, confirm that both Route 53 and aigw return identical answers for every record you care about.

For each critical record, ask both nameservers directly:

# Route 53 (replace ns-NNN with your actual R53 nameserver)
dig @ns-123.awsdns-12.com www.example.com A

# aigw
dig @ns1.aigw.app www.example.com A

The ANSWER sections should be byte-identical (ignoring TTL countdown). If they differ, fix the aigw zone before proceeding, once you flip the delegation, resolvers will start getting the aigw answer.

Step 4: Flip the registrar (T-0)

At your domain registrar (IONOS, Cloudflare, Namecheap, Porkbun, AWS, wherever you actually bought the domain), change the nameservers from the Route 53 set (ns-XXX.awsdns-YY.{com,net,org,co.uk}) to aigw's:

ns1.aigw.app
ns2.aigw.app

The change typically appears in the wild within 5–30 minutes; resolvers honoring the short NS TTL you set in step 1 pick up the new delegation quickly. The workspace activation status in the aigw console flips to Active the moment the first real query lands.

Step 5: Monitor + decommission (T+1 day)

Watch the aigw overview for 24 hours. You should see query volume ramp up as resolvers across the world pick up the new delegation. Route 53 query volume for the same zone should drop in CloudWatch over the same window.

Once Route 53 traffic for the zone is at zero (or down to background noise from stale-cache resolvers), delete the Route 53 hosted zone. Don't delete it earlier , even after the registrar switch, holding the old zone is a free hedge in case something goes wrong.

What about GSLB?

If you're using Route 53's failover, weighted, or geo routing, recreate the equivalent in aigw with a health-checked pool or a GEO record. The resolver-visible answers are equivalent; the data model differs:

POOL + active-passive: primary / backup with health-check fallback (replaces R53 failover)
POOL + weighted: multiple members with weights (replaces R53 weighted)
GEO: per-continent target list (replaces R53 geolocation)
CANARY: timed traffic ramp for blue/green rollouts (no R53 equivalent)

aigw doesn't do Route 53's latency-based routing. For "send users to the nearest region," use a GEO record (per-continent) plus health-checked pools, see the pools guide.

Questions or need help?

Email hello@aigw.app with your domain and which step you're stuck on. We'll respond within a day, often within an hour.