Migracja domeny i DNSzero downtime cutover na DevStudioIT Cloud w 2026

TL;DR

Migracja domeny to nie tylko zmiana rekordu A — to zsynchronizowany cutover DNS, certyfikatu SSL, redirectów 301 i weryfikacji poczty. Zero downtime w 2026 wymaga obniżenia TTL na 48 h przed zmianą, równoległego działania starego i nowego hostingu oraz testów na staging.example.com. Poniżej plan krok po kroku dla Next.js na DevStudioIT Cloud z danymi aplikacji w Branchly.

Dla kogo

• Firm zmieniających hosting lub rebrandujących domenę (firma.pl → firma.com)
• IT przenoszących stronę z shared hostingu na DevStudioIT Cloud
• Agencji kończących projekt u klienta i przekazujących DNS
• Właścicieli domen bojących się „czarnego ekranu na 24 h”

Fraza (SEO)

migracja domeny zero downtime, dns ttl cutover, przeniesienie strony hosting, zmiana domeny seo 301

Fazy migracji — timeline

Nie zaczynaj cutover w piątek po 15:00 — propagacja DNS + rollback wymaga czasu.

Inwentaryzacja DNS — co nie może zginąć

Przed zmianą wyeksportuj strefę z obecnego registrara:

example.com.     A      203.0.113.10        ; stary hosting
www.example.com. CNAME  example.com.
example.com.     MX 10  mail.provider.com.  ; poczta — NIE ruszaj bez planu
example.com.     TXT    "v=spf1 include:..."
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; ..."

Typowe pułapki:

• MX — strona idzie na DevStudioIT Cloud, poczta zostaje u Google — tylko A/CNAME www się zmienia
• TXT — weryfikacja Google Search Console, Stripe, Facebook Pixel
• CAA — blokuje Let's Encrypt jeśli źle ustawione
• Subdomeny — api., staging., old. — każda osobno

Aplikacja (formularze, dane) w Branchly (branchly.cloud) — migracja DNS nie dotyka bazy. Zmieniasz tylko APP_URL w env na DevStudioIT Cloud po cutover.

Obniżenie TTL — dlaczego 48 h wcześniej

TTL (Time To Live) mówi resolverom DNS, jak długo cache'ować rekord. Przy TTL 86400 (24 h) po zmianie A część użytkowników widzi starą stronę przez dobę.

Procedura:

1. Ustaw TTL=300 na A, AAAA, CNAME dla @ i www
2. Odczekaj poprzedni TTL max (często 24–48 h)
3. Dopiero wtedy wykonaj cutover

Narzędzia: dig example.com +trace, whatsmydns.net — sprawdź globalną propagację.

Deploy na DevStudioIT Cloud przed cutover

DevStudioIT Cloud (devstudioit.cloud) dostarcza IP lub CNAME target dla Twojej aplikacji Next.js:

; docelowo po cutover
www.example.com.  CNAME  app-xyz.devstudioit.cloud.
example.com.      A      198.51.100.42   ; lub ALIAS/ANAME u registrara

Przed cutover:

1. Dodaj subdomenę preview.example.com → nowy hosting
2. Certyfikat SSL (automatyczny Let's Encrypt po weryfikacji DNS)
3. Test: formularz → Branchly, obrazy, i18n, /robots.txt, /sitemap.xml
4. curl -I https://preview.example.com — 200, HSTS opcjonalnie

Cutover — sekwencja zero downtime

1. Maintenance off — oba środowiska działają równolegle
2. Zmień rekordy DNS na nowy target (najpierw www, potem apex @)
3. Monitoruj przez 15 min: dig @8.8.8.8 www.example.com
4. Stary hosting: włącz 301 redirect całej domeny na HTTPS nowej (backup gdy ktoś trafi na stary IP przez cache)
5. Zaktualizuj env: APP_URL=https://www.example.com
6. Wyślij test formularza i mail transakcyjny

Jeśli coś pójdzie źle — przy TTL 300 rollback rekordu trwa minuty, nie godziny.

SSL/TLS i mixed content

• Cert na nowym hostingu musi obejmować example.com i www.example.com (SAN)
• W Next.js next.config.js: images.domains / remote patterns po migracji CDN
• Wymuś redirect HTTP→HTTPS i www↔apex zgodnie z kanoniczną wersją (jedna decyzja SEO)

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

SEO i redirecty 301

• Stare URL-e (inna struktura ścieżek) — mapa 301 w Next.js redirects() lub edge config
• Google Search Console: dodaj nową właściwość, Change of Address jeśli tylko domena się zmienia
• Zaktualizuj sitemap.xml, canonical, hreflang
• NIE usuwaj starego hostingu przez 30 dni — redirecty i logi 404

Poczta i integracje po migracji

• SPF/DKIM/DMARC — jeśli wysyłka z @example.com bez zmian providera, rekordy TXT zostają
• Webhooki (Stripe, Branchly cron) — zaktualizuj URL w panelach zewnętrznych
• OAuth redirect URI (Google Login) — nowa domena w konsoli Google Cloud

Checklist po cutover (1 h)

• Strona główna i 5 kluczowych podstron — 200 OK
• Formularz kontaktowy → wpis w Branchly + mail
• SSL Labs grade A
• robots.txt, sitemap.xml dostępne
• Brak mixed content w DevTools
• Stary hosting — 301 na nową domenę
• Monitoring uptime (np. ping co 1 min przez 24 h)

Monitoring i rollback — plan B

Przed cutover przygotuj runbook w Branchly (notatka wewnętrzna) z dokładnymi wartościami rekordów sprzed zmiany — screenshot strefy DNS i export TXT. W pierwszej godzinie obserwuj:

• Uptime robot z trzech regionów (EU, US, APAC)
• Logi 5xx na DevStudioIT Cloud — spike po cutover często oznacza zły APP_URL lub brak env
• Google Analytics realtime — czy ruch wraca na właściwą domenę

Rollback: przywróć poprzednie A/CNAME z runbooka. Przy TTL 300 większość resolverów wraca w <15 min. Komunikat status page tylko jeśli rollback trwa dłużej niż 30 min — przy dobrym planie rzadko potrzebny.

FAQ

Czy zero downtime gwarantuje 100% użytkowników?

Przy TTL 300 praktycznie tak dla HTTP. Resztkowy cache DNS u niektórych ISP może trwać do starego TTL sprzed obniżenia — stąd równoległy redirect na starym serwerze.

CNAME na apex (@)?

Zależy od registrara — Cloudflare CNAME flattening, ANAME u DNS Made Easy, lub rekord A na stałe IP DevStudioIT Cloud.

Czy zmiana NS (nameserverów) to to samo co A?

Zmiana NS przenosi całą strefę — ryzykowne bez pełnej kopii rekordów. Preferuj zmianę pojedynczych rekordów u obecnego DNS.

Jak długo trzymać stary hosting?

Minimum 30 dni (redirecty + rollback). Przy zmianie domeny — 90 dni 301 ze starej domeny.

Czy Branchly wymaga migracji?

Nie — connection string bez zmian. Tylko APP_URL i ewentualnie CORS / allowed origins.

CTA

Planujesz migrację domeny lub cutover na nowy hosting bez przestoju?

• Zaplanuj migrację z nami — DNS, SSL, redirecty, DevStudioIT Cloud + Branchly
• Hosting strony WWW — porównanie i SLA