Domain-Migration und DNSZero-Downtime-Cutover auf DevStudioIT Cloud 2026

TL;DR

Domain-Migration ist nicht nur ein A-Record — es ist synchronisierter Cutover von DNS, SSL-Zertifikat, 301-Weiterleitungen und Mail-Verifikation. Zero Downtime 2026 erfordert TTL-Absenkung 48 h vorher, parallelen Betrieb alt/neu und Tests unter staging.example.com. Schritt-für-Schritt-Plan für Next.js auf DevStudioIT Cloud mit App-Daten in Branchly folgt.

Für wen

• Unternehmen mit Hosting-Wechsel oder Domain-Rebrand (firma.de → firma.com)
• IT, die von Shared Hosting auf DevStudioIT Cloud umzieht
• Agenturen mit DNS-Übergabe an Kunden
• Domain-Inhaber mit Angst vor „24 h schwarzem Bildschirm“

Keyword (SEO)

domain migration zero downtime, dns ttl cutover, website hosting umzug, domain wechsel seo 301

Migrationsphasen — Timeline

Kein Cutover freitags nach 15 Uhr — DNS-Propagation und Rollback brauchen Zeit.

DNS-Inventar — was nicht verloren gehen darf

Zone vom aktuellen Registrar exportieren:

example.com.     A      203.0.113.10        ; altes Hosting
www.example.com. CNAME  example.com.
example.com.     MX 10  mail.provider.com.  ; Mail — nicht ohne Plan anfassen
example.com.     TXT    "v=spf1 include:..."
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; ..."

Typische Fallen:

• MX — Website auf DevStudioIT Cloud, Mail bleibt bei Google — nur www A/CNAME ändert sich
• TXT — Google Search Console, Stripe, Facebook Pixel
• CAA — blockiert Let's Encrypt bei Fehlkonfiguration
• Subdomains — api., staging., old. — jeweils einzeln

App-Daten (Formulare) in Branchly (branchly.cloud) — DNS-Migration berührt die DB nicht. Nur APP_URL in env auf DevStudioIT Cloud nach Cutover.

TTL senken — warum 48 h vorher

TTL sagt Resolvern, wie lange ein Record gecacht wird. Bei TTL 86400 (24 h) sehen nach A-Änderung manche Nutzer einen Tag die alte Seite.

Vorgehen:

1. TTL=300 auf A, AAAA, CNAME für @ und www
2. Vorheriges max TTL abwarten (oft 24–48 h)
3. Erst dann Cutover

Tools: dig example.com +trace, whatsmydns.net

Deploy auf DevStudioIT Cloud vor Cutover

DevStudioIT Cloud (devstudioit.cloud) liefert IP oder CNAME-Ziel für Next.js:

; nach Cutover
www.example.com.  CNAME  app-xyz.devstudioit.cloud.
example.com.      A      198.51.100.42   ; oder ALIAS/ANAME beim Registrar

Vor Cutover:

1. Subdomain preview.example.com → neues Hosting
2. SSL (automatisch Let's Encrypt nach DNS-Verifikation)
3. Test: Formular → Branchly, Bilder, i18n, /robots.txt, /sitemap.xml
4. curl -I https://preview.example.com — 200

Cutover — Zero-Downtime-Sequenz

1. Kein Maintenance Mode — beide Umgebungen parallel
2. DNS auf neues Ziel (zuerst www, dann Apex @)
3. 15 Min monitoren: dig @8.8.8.8 www.example.com
4. Altes Hosting: 301-Redirect gesamte Domain auf neues HTTPS
5. Env: APP_URL=https://www.example.com
6. Test-Formular und Transaktionsmail

Bei Fehler — mit TTL 300 Rollback in Minuten, nicht Stunden.

SSL/TLS und Mixed Content

• Zertifikat muss example.com und www.example.com abdecken (SAN)
• Next.js next.config.js: images.domains nach CDN-Migration
• HTTP→HTTPS und www↔apex gemäß kanonischer SEO-Entscheidung

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

SEO und 301-Weiterleitungen

• Alte URLs — 301-Map in Next.js redirects() oder Edge-Konfiguration
• Google Search Console: neue Property, Change of Address bei reiner Domain-Änderung
• sitemap.xml, canonical, hreflang aktualisieren — gleiche translationId in Blog-Frontmatter für hreflang
• Altes Hosting 30 Tage nicht löschen — Redirects und 404-Logs für SEO-Audit

Bei Rebrand (alt.de → neu.de): 301 von jeder indexierten URL, nicht nur Startseite. Search Console „Seiten“ → exportierte nicht indexierte URLs prüfen.

Monitoring und Rollback — Plan B

Vor Cutover Runbook in Branchly: exakte DNS-Werte vor Änderung, Screenshot der Zone, TXT-Export. In der ersten Stunde:

• Uptime von drei Regionen (EU, US, APAC)
• 5xx-Logs auf DevStudioIT Cloud — Spike oft durch falsches APP_URL
• Analytics Realtime — Traffic auf korrekter Domain

Rollback: alte A/CNAME aus Runbook. Bei TTL 300 meist <15 Min. Statusseite nur bei Rollback >30 Min.

Mail und Integrationen nach Migration

• SPF/DKIM/DMARC bei gleichem Mail-Provider unverändert lassen
• Webhooks (Stripe, Cron) — URL in externen Panels aktualisieren
• OAuth Redirect URI — neue Domain in Google Cloud Console
• Formular-Daten in Branchly — kein DB-Migrate, nur APP_URL und CORS

Checkliste nach Cutover (1 h)

• Startseite + 5 Kernseiten — 200 OK
• Kontaktformular → Branchly + Mail
• SSL Labs Grade A
• robots.txt, sitemap.xml erreichbar
• Kein Mixed Content
• Altes Hosting — 301 auf neue Domain
• Uptime-Monitoring 24 h

FAQ

Zero Downtime = 100 % der Nutzer?

Mit TTL 300 praktisch ja für HTTP. Restlicher DNS-Cache bei ISPs bis zum alten TTL — daher paralleler Redirect auf altem Server.

CNAME auf Apex (@)?

Registrar-abhängig — Cloudflare Flattening, ANAME, oder A auf DevStudioIT Cloud IP.

NS-Wechsel = A-Record?

NS-Wechsel verschiebt ganze Zone — riskant ohne Record-Kopie. Einzelne Records bevorzugen.

Altes Hosting wie lange?

Mindestens 30 Tage. Nur Domain-Wechsel — 90 Tage 301 von alter Domain.

Branchly migrieren?

Nein — Connection String gleich. Nur APP_URL und ggf. CORS.

CTA

Domain-Migration oder Cutover ohne Ausfall geplant?

• Migration planen — DNS, SSL, Redirects, DevStudioIT Cloud + Branchly
• Website-Hosting — Vergleich und SLA