Migracja domeny i DNS, zero 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