En svensk webbplats kan se enkel ut från utsidan men bestå av många beroenden: apexdomän, www, inloggning, bilder, API, kundportal, formulär, e-post och gamla kampanjadresser. Vid en migrering flyttar du inte bara filer. Du ändrar DNS-svar, certifikat, omdirigeringar och ibland cookies eller brandväggsregler. Om planeringen saknar en hostname kan kunder möta ett gammalt certifikat, en felaktig server eller en omdirigeringskedja som aldrig når den nya webbplatsen.
Planera därför DNS och TLS tillsammans med webbteamet, inte som två separata checklistor. Ett certifikat måste täcka rätt namn på den nya miljön innan DNS pekar dit. DNS-ändringen måste kunna rullas tillbaka utan att gamla certifikat eller gamla poster har raderats. E-post ska vara uttryckligen skyddad från en webbändring. Ett lyckat webbtest på startsidan bevisar inte att kundservice, API och återställningslänkar fungerar.
Börja med en hostname-inventering
Lista alla namn som användare, integrationer och sökmotorer kan nå. Ta med apex, www, admin, login, konto, api, static, images, webhook, status, test och gamla kampanjnamn. Använd dokumentation, DNS, certifikatobservationer, webbserverloggar och kontakt med produktägare. Markera varje namn som ska flyttas, ligga kvar, omdirigeras eller avvecklas. Ett namn som inte ska ha en webbplats kan ändå behöva DNS för e-post eller verifiering.
- Hostname och avsedd funktion.
- DNS-post, TTL, IPv4 och IPv6.
- Certifikatets namn, utgångstid och förnyelseägare.
- Nuvarande och ny tjänsteägare.
- Omdirigeringsregel och slutlig URL.
- Kritiskhet, testfall och rollbackmetod.
Kontrollera sedan certifikaten från användarens perspektiv. Verifiera subject alternative names, giltighet, kedja, protokoll och hur servern svarar när klienten anger rätt SNI-hostname. Ett certifikat för www täcker inte automatiskt api eller en annan subdomän. Spara observationen med datum och koppla den till den planerade nya lösningen. Om certifikatet automatiskt förnyas behöver någon ändå äga DNS-valideringen och övervaka att förnyelsen fortsätter efter bytet.
Förbered den nya webbmiljön före DNS
Publicera den nya webbplatsen på en tillfällig testadress eller intern väg som inte ersätter den publika domänen. Installera certifikat för alla planerade hostnames och testa applikationens absoluta URL:er, cookies, formulär, webhooks och API-anrop. Kontrollera att robots- och sitemapbeteende är korrekt för lanseringen. Använd inte en öppen testhost med kunddata som om den vore en harmlös förhandsvisning.
Verifiera webbläsare, mobil, IPv4 och IPv6. Många migreringar testar bara den vanligaste vägen och upptäcker senare att AAAA-posten leder till den gamla miljön. Testa även HTTP till HTTPS, www till apex eller motsatt vald kanonisk adress, trailing slash, språkvägar och gamla länkar. Omdirigeringar bör vara korta, avsiktliga och utan kedjor. Dokumentera en lista över URL:er som ska ge 200, 301, 404 eller ett annat förväntat resultat.
Hantera TTL och ändringsfönster realistiskt
TTL påverkar hur länge resolvrar kan behålla ett svar, men den garanterar inte att alla cachear byter samtidigt. Sänk TTL i god tid före ett planerat byte och kontrollera auktoritativ zon, inte bara den lokala datorns cache. Om du sänker värdet minuter före ändringen kan gamla svar ändå leva kvar och det blir svårare att förstå resultatet. Sätt tillbaka ett rimligt värde först när stabiliteten är bekräftad.
Välj ett ändringsfönster med bemanning från DNS, webb, e-post, säkerhet och kundservice. Skriv exakta start- och stoppkriterier, vem som får ändra en post och hur en rollback godkänns. Kommunicera planerad påverkan internt, men lova inte att cache eller externa nät följer den exakta klockan. Följ verkliga svar från flera nät och mät applikationens hälsa under hela fönstret.
Glöm inte MX och andra DNS-poster
En webbzon innehåller ofta mer än A och CNAME. MX, SPF, DKIM, DMARC, TXT för verifiering, CAA, SRV och eventuella DNSSEC-poster måste jämföras med baslinjen. Ändra inte e-postposter bara för att webbplatsen byter server. Om en ny DNS-zon byggs från en ofullständig mall kan företagets fakturor eller lösenordsåterställningar sluta fungera trots att startsidan ser perfekt ut.
Låt e-postägaren godkänna varje ändring av MX och SPF. Kontrollera att gamla verifieringsposter bara tas bort när respektive tjänst har flyttats eller avslutats. Om DNSSEC är aktiverat följer en separat plan för DS och signering. Dokumentera skillnaden mellan avsiktliga borttagningar och poster som saknas på grund av ett kopieringsfel.
Testa certifikat och omdirigeringar efter bytet
När DNS har ändrats kontrollerar du varje hostname från flera nät. Läs certifikatets namn och kedja, följ omdirigeringen och kontrollera den slutliga statuskoden. Öppna kritiska flöden från en ny session: login, kundvagn, betalning, formulär, API-token, återställning och nedladdning. Kontrollera att inga interna testadresser läcker i HTML, headers eller länkar. Ett grönt TLS-betyg kan inte ersätta ett fungerande verksamhetsflöde.
- Kontrollera apex och www över IPv4 och IPv6.
- Verifiera alla certifikatnamn och kedjor.
- Följ HTTP- och HTTPS-omdirigering till slutlig URL.
- Testa statiskt innehåll, formulär, inloggning och API.
- Kontrollera MX, SPF, DKIM, DMARC och verifieringsposter.
- Följ fel, latens och kundärenden under cachefönstret.
- Spara före- och efterbevis samt beslut om stängning eller rollback.
Planera rollback utan att skapa dubbla fel
Rollback är inte bara att peka A-posten tillbaka. Den nya miljön kan ha skapat data, sessioner eller betalningshändelser som inte finns i den gamla. Bestäm om rollback gäller hela trafiken, en viss hostname eller enbart omdirigering. Behåll gamla certifikat, DNS-poster och kontaktvägar till dess att den nya miljön passerat avtalad observationsperiod. Skriv vilka signaler som utlöser rollback och vem som fattar beslutet.
Om felet gäller certifikat kan en omedelbar DNS-ändring göra problemet större genom att cachear blandas. Fixa först ett fel som går att rätta i den nya miljön om tjänsten är nåbar, eller följ den godkända rollbackvägen om risknivån är hög. Dokumentera exakt när varje åtgärd gjordes. Efter en rollback behövs en ny baslinje, inte bara en förklaring om att det fungerade igen.
Avveckla den gamla miljön kontrollerat
Stäng inte gamla servrar direkt efter att en monitor visar 200. Vänta tills DNS-cache, certifikatförnyelse, webhookar, bokmärken och externa integrationer har passerat avtalad kontroll. Leta efter trafik på gamla hostnames och fråga varje systemägare om beroenden. Ta bort gamla DNS-poster och åtkomster i planerade steg. En server som lämnas kvar utan ägare är en risk, men en server som tas bort utan att någon vet om ett gammalt API används skapar också störning.
Gör migreringen återanvändbar
Spara en mall med hostname-inventering, DNS-diff, certifikatlista, testfall, ägare, ändringsfönster, mätpunkter och rollback. Efteråt skriver du en kort lessons learned: vilka namn saknades, vilken observation var missvisande, vilken kontroll hittade felet först och vilka poster kunde avvecklas. Nästa webbbyte blir då ett förbättrat arbetssätt i stället för en ny improvisation.
En trygg svensk DNS- och TLS-migrering handlar om disciplin i små detaljer. Inventera innan du ändrar, installera certifikat före pekning, testa mer än startsidan, skydda e-postposterna och följ cache från flera nät. När gamla och nya miljöer har tydliga ägare och en gemensam baslinje kan teamet byta utan att blanda ihop ett certifikatfel med ett DNS-fel eller en applikationsbugg.
Låt en person som inte utförde ändringen göra slutkontrollen. Den andra blicken ska jämföra den överenskomna listan med verkliga svar och försöka nå tjänsten som kund, medarbetare och integration. Om något inte är verifierat ska ändringen förbli öppen eller få ett tydligt accepterat undantag. Den enkla kontrollen gör en stor skillnad när flera team delar samma domän.
Hantera externa integrationer
Be systemägare lista webhookar, OAuth-redirects, betalningsleverantörer, kundportalens länkar och API-klienter som använder den gamla hosten. En DNS-migrering kan göra webbläsartrafiken korrekt men lämna en integration med hårdkodad adress eller certifikatpinning. Sätt testfall för varje kritiskt beroende och be leverantören bekräfta att den nya adressen är godkänd. Lägg inte till en långvarig omdirigering som enda lösning om klienten behöver ett permanent URL-byte.
Kontrollera också cookies och säkerhetsheaders på den nya hosten. Ett byte av apex till www eller en annan subdomän kan påverka SameSite, Secure, HSTS och tillåtna origin. Testa utloggning och återställning, inte bara att en redan inloggad webbläsare visar sidan. Om en kund får ett certifikatfel kan supporten behöva en kort instruktion och ett internt eskaleringsnummer under ändringsfönstret.
Följ upp efter en vecka
Efter migreringen jämför du trafik, felkoder, certifikatförnyelse, DNS-svar och kundärenden med baslinjen. Leta efter lågvolymflöden som bara körs en gång per vecka, till exempel rapporter, batchimporter eller fakturor. Kontrollera att den gamla miljön inte fortfarande tar emot känsliga anrop och att nya DNS-poster har rätt TTL. Först när observationsperioden är avslutad bör gamla konton, certifikat och åtkomster tas bort.
Skriv en kort slutrapport med vad som flyttades, vilka undantag som accepterades och när nästa certifikatförnyelse ska verifieras. Notera särskilt om certifikatet kräver DNS-validering eller manuell kontakt. Dokumentationen hjälper nästa team att förstå varför en CNAME, MX-post eller omdirigering finns kvar och minskar risken för att en framtida ändring raderar ett viktigt beroende.
Ta höjd för svenska arbetsdagar och kampanjer
Undvik ett byte precis före lönekörning, månadsfakturor, en stor svensk kampanj eller en helg då supporten är tunn. Identifiera även integrationer som körs enligt svensk tid eller månadsintervall och inte syns i normal webbtrafik. Lägg ändringsfönstret när DNS-, webb-, e-post- och verksamhetsägare kan svara. En lugn startsida på förmiddagen säger inget om ett nattligt exportjobb eller en kundportal som används först senare.
Gör en godkänd kommunikationsmall för interna team och support. Skriv vad som ändras, vilka tjänster som kan påverkas, hur man kontrollerar den riktiga adressen och vem som kontaktas vid certifikatfel. Lägg inte ut tekniska detaljer som avslöjar interna testnamn eller temporära adresser. Efteråt samlar ni kundärenden och mätdata i samma slutrapport så att beslutet kan förbättras nästa gång.
En migrering är också ett bra tillfälle att ta bort onödiga namn. Gör det först efter att länkar, certifikat, DNS, e-post och avtalsberoenden är granskade. Markera varje borttagning med ägare och återställningsperiod. Om en gammal host fortfarande får trafik ska den inte bara raderas i hast; utred källan och välj en säker avvecklingsväg.
Låt slutkontrollen omfatta en extern användare utan gamla cookies eller DNS-cache. Den personen ska kunna följa den officiella länken, få rätt certifikat, logga in, skicka ett testformulär och nå den avsedda slutadressen. Spara resultatet tillsammans med DNS- och TLS-observationen. Det visar att migreringen fungerar i praktiken, inte bara i det team som redan känner till den nya miljön.