Domain migration and DNSzero 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