Flytt nettstedet med kontrollert overgang og trygg rollback

En nettsideflytting kan gjennomføres uten merkbart avbrudd, men «ingen nedetid» kan ikke garanteres av en DNS-oppskrift alene. I overgangsperioden kan noen brukere nå gammel løsning og andre nå ny. Hvis begge tar imot ordre, skjema eller innhold, kan data bli delt mellom to steder.

En trygg migrering bygger derfor tre ting før trafikken flyttes:

1. et komplett og testet målsystem
2. en plan for data som endres under overgangen
3. en rollback som ikke sletter nye skrivninger

Bestem hva «vellykket» betyr

Skriv akseptansekriterier og feilgrenser før arbeidet starter:

Maksimalt tjenesteavbrudd: 5 minutter
Maksimalt datatap: 0 bekreftede ordre
Rollback utløses ved: betaling eller innlogging feiler i to tester
Beslutningseier: driftsansvarlig
Observasjonsperiode før oppsigelse: 14 dager

Tallene er eksempler, ikke standardkrav. En statisk firmaside og en nettbutikk trenger ulike planer.

1. Lag inventar over hele løsningen

Ikke begynn med å laste ned public_html. Kartlegg:

• alle domener, subdomener og URL-varianter
• DNS-sone, navnetjenere, TTL, DNSSEC og CAA
• filer, objektlagring, database og søkeindeks
• kjøretid, webserver, databaseversjon og systempakker
• cron, køer, bakgrunnsjobber og webhooks
• e-post fra nettsiden og mottakere av skjema
• betalings-, booking-, analyse- og samtykkeløsninger
• miljøvariabler, secrets og sertifikater
• redirects, sikkerhetsheadere, cache og WAF-regler
• logger, overvåking, varsling og backup
• eiere, leverandører og kontaktvei under cutover

Eksporter DNS-sonen og ta skjermbilder eller maskinlesbar kopi av konfigurasjon. En hostingflytting krever vanligvis ikke bytte av navnetjenere. Endre færrest mulig lag samtidig.

2. Mål dagens løsning

Ta en referanse som kan sammenlignes etter flyttingen:

• statuskode og respons for viktige URL-er
• TTFB og lastetid fra relevante steder
• Core Web Vitals-feltdata hvis tilgjengelig
• trafikk, feilrate, CPU, minne og databasebelastning
• kølengde og bakgrunnsjobber
• antall ordre, brukere, innlegg, filer og andre nøkkeldata
• e-postlevering og skjemaresultat

Noter tidspunkt og tidssone. Uten en baseline kan dere ikke vite om den nye løsningen er bedre, lik eller ødelagt på en måte som bare noen brukere merker.

3. Forbered DNS tidlig

Finn gjeldende TTL på postene som faktisk skal endres. Senk TTL minst én tidligere TTL-periode før cutover, gjerne med sikkerhetsmargin. Hvis A-posten har TTL 86 400 sekunder, må den gamle verdien få tid til å utløpe i cache før en ny TTL på for eksempel 300 sekunder får effekt.

Kontroller også:

• minimums-TTL hos DNS-leverandøren
• både A- og AAAA-poster
• www og andre vertsnavn
• CNAME-kjeder
• om CDN eller lastbalanserer er det egentlige trafikklaget
• negative cacheverdier hvis nye navn opprettes

Lav TTL gjør oppdateringer raskere, men tømmer ikke resolvercache som allerede inneholder den gamle, høyere TTL-en. Enkelte klienter og mellomledd kan også oppføre seg annerledes enn forventet. Les hvordan DNS-propagering faktisk virker før tidsplanen låses.

Endre ikke MX, SPF, DKIM eller DMARC når bare nettsiden skal flyttes. En feil ved kopiering av hele DNS-sonen kan ellers stoppe e-post.

4. Bygg målet med kompatible versjoner

Opprett den nye løsningen og dokumenter alle avvik fra kilden. Kontroller:

• støttet PHP-, Node-, database- eller CMS-versjon
• nødvendige utvidelser, filrettigheter og prosesser
• databaseinnstillinger, tegnsett, sortering og tidssone
• lagring, opplastingsgrenser og planlagte jobber
• utgående e-post, API-tilgang og tillatte IP-adresser
• miljøvariabler og nye secrets
• redirects, headers, cache og komprimering

Ikke kombiner hostingflytting, stor CMS-oppgradering, nytt tema og URL-endring i samme cutover med mindre dere har en særskilt test- og rollbackplan. Færre samtidige endringer gjør feil enklere å finne.

5. Kopier data konsistent

En første kopi kan tas mens gammel løsning er i drift, men dere må vite hva som skjer etter kopitidspunktet.

Filer

Kopier kode, opplastinger og andre nødvendige filer gjennom en kryptert kanal. Kontroller antall, størrelse og ved behov hashverdier. Ikke kopier kompromitterte cachefiler, secrets eller midlertidige data ukritisk.

Database

En logisk eksport må representere en konsistent tilstand. En hurtigeksport fra et nettgrensesnitt kan få tidsavbrudd eller bli inkonsistent mens tabeller endres. Bruk databaseproduktets dokumenterte backup- eller replikeringsmetode, og test importen mot målversjonen.

Guiden om database for nettsider beskriver transaksjoner, kompatibilitet og validering.

Data som endres etter første kopi

Velg én dokumentert metode:

• gjør den gamle løsningen skrivebeskyttet under siste synkronisering
• stopp publisering, ordre og skjema i et kort vedlikeholdsvindu
• repliker databaseendringer frem til cutover
• bruk plattformens eksport- og migreringsfunksjon med endringslogg
• kø skrivninger kontrollert og spill dem inn på nytt etter byttet

«Kopier databasen og bytt DNS» er ikke nok for en aktiv tjeneste.

6. Skaff HTTPS før trafikken flyttes

Målet må kunne svare med gyldig sertifikat for de virkelige vertsnavnene før offentlig DNS peker dit. Hvordan det gjøres avhenger av plattform og sertifikatutsteder:

• DNS-validering kan ofte gjøres før trafikkskiftet
• en plattform kan tilby en forhåndsvalidering eller midlertidig CNAME
• et eksisterende, eksportérbart sertifikat kan eventuelt installeres sikkert
• ACME HTTP-validering kan kreve at riktig valideringsrute når målet

Ikke flytt trafikken først og aktiver HTTPS etterpå. Da kan brukerne møte sertifikatfeil, og HSTS kan gjøre HTTP-reserve umulig. Bruk HTTPS-oppsettet for webhotell til å kontrollere kjede, vertsnavn og automatisk fornyelse.

7. Test målet med riktig vertsnavn

En midlertidig leverandør-URL tester ikke nødvendigvis redirects, cookies, CORS, cache eller sertifikatet for domenet. Test den nye IP-en eller origin med det virkelige vertsnavnet og korrekt TLS SNI.

En lokal hosts-oppføring kan brukes for enkelte oppsett, men:

• den gjelder bare den enheten som er endret
• den overstyrer ikke nødvendigvis CDN, DoH eller applikasjonsspesifikk DNS
• den tester ikke offentlig ruting for andre brukere
• den må fjernes etter testen

Test minst:

• HTTP til HTTPS og foretrukket www-variant
• hovedsider, statuskoder, canonical og redirects
• innlogging, passordreset og roller
• skjema og faktisk mottak av testmeldingen
• søk, opplasting og nedlasting
• ordre, betaling, kvittering og tilbakebetaling i testmodus
• API-er, webhooks, køer og cron
• mobil, tastatur og kritiske nettlesere
• at staging, debug og kataloglisting ikke er offentlig
• logger, backup og varsling på målet

Bruk tydelig merkede testdata og slett dem etterpå.

8. Kjør en kontrollert cutover

Ha begge leverandører og beslutningseier tilgjengelig. Følg en tidsstemplet sjekkliste:

1. Stopp eller kontroller nye skrivninger etter valgt strategi.
2. Ta siste konsistente kopi eller la replikering ta igjen etterslepet.
3. Valider nøkkeltall og kritiske data på målet.
4. Stopp bakgrunnsjobber på gammel løsning slik at de ikke kjøres dobbelt.
5. Start nødvendige jobber på målet.
6. Endre bare DNS-postene som skal flytte webtrafikk.
7. Noter DNS-verdi, tidspunkt, TTL og hvem som gjorde endringen.
8. Kjør syntetiske tester fra flere resolver- og nettverkssteder.
9. Følg trafikk og feil på både gammel og ny løsning.

La den gamle løsningen vise normalt innhold eller en kontrollert beskjed så lenge den kan motta resttrafikk. Ikke slett den straks DNS er endret.

9. Overvåk selve overgangen

Følg mer enn forsiden:

• andel trafikk og requests på gammel og ny origin
• 4xx-, 5xx- og applikasjonsfeil
• sertifikat-, DNS- og tilkoblingsfeil
• innlogging, ordre, skjema og e-post
• databasefeil, kø og bakgrunnsjobber
• uventede redirects og cachetreff
• CPU, minne, disk, forbindelser og responstid
• Search Console og analyse for uventede fall etterpå

Logg alle handlinger og avvik. Hold supportkanaler og en synlig statusmelding klare dersom kundene påvirkes.

10. Rollback uten å miste nye data

Å peke DNS tilbake er bare enkel rollback når målet ikke har tatt imot nye skrivninger. Hvis det finnes nye ordre, kontoer, skjemadata eller opplastinger på målet, kan en rask retur til gammel database skjule eller overskrive dem.

Rollbackplanen må derfor angi:

• hvilke feil som utløser retur
• hvem som tar beslutningen
• hvordan nye skrivninger stoppes eller eksporteres
• hvordan data på gammel og ny side sammenstilles
• hvilke jobber som må stoppes og startes
• hvilken DNS-verdi som gjenopprettes
• hvordan brukere og interne team informeres

Test rollback i øvelsen før migreringsdagen. En plan som ikke kan bevare nye data er bare en trafikkretur, ikke full gjenoppretting.

11. Etter at trafikken er stabil

• behold gammel løsning gjennom avtalt observasjons- og rollbackperiode
• verifiser at resttrafikken faktisk har stoppet
• gjenopprett normal DNS-TTL når det ikke er planlagt nye endringer
• test full backup og restore på ny plattform
• oppdater inventar, diagrammer, tilgangslister og beredskapsplan
• roter midlertidige secrets og fjern migreringstilganger
• avslutt gamle jobber, overvåking og leverandøravtaler kontrollert
• hent nødvendig data og slett gamle kopier etter avtale og personvernkrav

Sjekk også at URL-er, statuskoder, canonical, robots, sitemap og analyse er uendret hvis flyttingen ikke skulle endre nettstedets informasjonsarkitektur. Hostingflytting alene krever normalt ikke nye URL-er.

Vymo og flytting av eksisterende nettsted

Vymos standardtilbud er én ny, enkel bedriftsnettside som Vymo setter opp og hoster. Det er ikke et generelt webhotell med selvbetjent database, SFTP eller WordPress-migrering, og Vymo lover ikke en nedetidsfri flyttetjeneste som del av standardtilbudet.

Hvis et eksisterende nettsted skal flyttes, beskriv plattform, datakilder, trafikk, integrasjoner og krav til cutover før det gis tilbud. Trenger virksomheten bare en ny, avgrenset presentasjonsside, se hva den enkle nettsiden inkluderer .