Domain migration and DNS, zero downtime cutover to DevStudioIT Cloud in 2026

TL;DR

Domain migration is not just changing an A record, it is synchronized cutover of DNS, SSL certificate, 301 redirects and mail verification. Zero downtime in 2026 requires lowering TTL 48 h before the change, running old and new hosting in parallel and testing on staging.example.com. Below: step-by-step plan for Next.js on DevStudioIT Cloud with app data in Branchly.

Who this is for

• Companies changing host or rebranding domain (company.co.uk → company.com)
• IT moving a site from shared hosting to DevStudioIT Cloud
• Agencies handing off a client project and DNS
• Domain owners afraid of “a black screen for 24 h”

Keyword (SEO)

domain migration zero downtime, dns ttl cutover, website hosting transfer, domain change seo 301

Migration phases, timeline

Do not cut over Friday after 3 PM, DNS propagation and rollback need time.

DNS inventory, what must not disappear

Export the zone from your current registrar first:

example.com.     A      203.0.113.10        ; old hosting
www.example.com. CNAME  example.com.
example.com.     MX 10  mail.provider.com.  ; mail, do not touch without a plan
example.com.     TXT    "v=spf1 include:..."
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; ..."

Common traps:

• MX, site moves to DevStudioIT Cloud, mail stays on Google, only www A/CNAME changes
• TXT, Google Search Console, Stripe, Facebook Pixel verification
• CAA, blocks Let's Encrypt if misconfigured
• Subdomains, api., staging., old., each separately

App data (forms, records) in Branchly (branchly.cloud), DNS migration does not touch the database. You only update APP_URL in env on DevStudioIT Cloud after cutover.

Lowering TTL, why 48 h ahead

TTL tells DNS resolvers how long to cache a record. With TTL 86400 (24 h) after an A change some users see the old site for a day.

Procedure:

1. Set TTL=300 on A, AAAA, CNAME for @ and www
2. Wait previous max TTL (often 24–48 h)
3. Only then perform cutover

Tools: dig example.com +trace, whatsmydns.net, check global propagation.

Deploy on DevStudioIT Cloud before cutover

DevStudioIT Cloud (devstudioit.cloud) provides IP or CNAME target for your Next.js app:

; after cutover
www.example.com.  CNAME  app-xyz.devstudioit.cloud.
example.com.      A      198.51.100.42   ; or ALIAS/ANAME at registrar

Before cutover:

1. Add subdomain preview.example.com → new hosting
2. SSL certificate (automatic Let's Encrypt after DNS verification)
3. Test: form → Branchly, images, i18n, /robots.txt, /sitemap.xml
4. curl -I https://preview.example.com, 200, HSTS optional

Cutover, zero downtime sequence

1. No maintenance mode, both environments run in parallel
2. Change DNS records to new target (first www, then apex @)
3. Monitor 15 min: dig @8.8.8.8 www.example.com
4. Old hosting: enable 301 redirect entire domain to new HTTPS (backup for cached old IP)
5. Update env: APP_URL=https://www.example.com
6. Send test form submission and transactional mail

If something fails, with TTL 300 record rollback takes minutes, not hours.

SSL/TLS and mixed content

• Cert on new host must cover example.com and www.example.com (SAN)
• Next.js next.config.js: images.domains / remote patterns after CDN migration
• Enforce HTTP→HTTPS and www↔apex per canonical SEO choice

// next.config.js, apex → www example
async redirects() {
  return [
    {
      source: '/:path*',
      has: [{ type: 'host', value: 'example.com' }],
      destination: 'https://www.example.com/:path*',
      permanent: true,
    },
  ];
}

SEO and 301 redirects

• Old URLs (different path structure), 301 map in Next.js redirects() or edge config
• Google Search Console: add new property, Change of Address if only domain changed
• Update sitemap.xml, canonical, hreflang
• Do NOT delete old hosting for 30 days, redirects and 404 logs

Mail and integrations after migration

• SPF/DKIM/DMARC, if sending from @example.com with same provider, TXT records stay
• Webhooks (Stripe, Branchly cron), update URL in external panels
• OAuth redirect URI (Google Login), new domain in Google Cloud console

Post-cutover checklist (1 h)

• Homepage and 5 key pages, 200 OK
• Contact form → Branchly entry + mail
• SSL Labs grade A
• robots.txt, sitemap.xml reachable
• No mixed content in DevTools
• Old hosting, 301 to new domain
• Uptime monitoring (ping every 1 min for 24 h)

Monitoring and rollback, plan B

Before cutover prepare a runbook in Branchly (internal note) with exact pre-change record values, DNS zone screenshot and TXT export. In the first hour watch:

• Uptime checks from three regions (EU, US, APAC)
• 5xx logs on DevStudioIT Cloud, post-cutover spike often means wrong APP_URL or missing env
• Google Analytics realtime, traffic on the correct domain

Rollback: restore previous A/CNAME from the runbook. With TTL 300 most resolvers revert in under 15 min. Status page message only if rollback exceeds 30 min, rarely needed with a solid plan.

FAQ

Does zero downtime mean 100% of users?

With TTL 300 practically yes for HTTP. Residual DNS cache at some ISPs may last until old TTL before lowering, hence parallel redirect on old server.

CNAME on apex (@)?

Depends on registrar, Cloudflare CNAME flattening, ANAME at DNS Made Easy, or A record to DevStudioIT Cloud IP.

Is changing NS the same as A?

Changing NS moves the whole zone, risky without full record copy. Prefer changing individual records at current DNS.

How long to keep old hosting?

Minimum 30 days (redirects + rollback). Domain change only, 90 days 301 from old domain.

Does Branchly need migration?

No, connection string unchanged. Only APP_URL and possibly CORS / allowed origins.

CTA

Planning domain migration or cutover to new hosting without downtime?

• Plan migration with us, DNS, SSL, redirects, DevStudioIT Cloud + Branchly
• Website hosting, comparison and SLA