Sådan flytter du din hjemmeside til en ny webhost uden nedetid

Det lyder risikabelt at flytte en hjemmeside til en ny webhost, men med en klar plan er det et roligt og forudsigeligt stykke arbejde. Tricket er at bygge og teste den nye kopi, mens den gamle stadig betjener besøgende, og først derefter lade dit domæne pege videre. Denne guide gennemgår hele processen for en typisk lille hjemmeside. WordPress er hovedeksemplet, og statiske sider og egne PHP-sider er omtalt mere overordnet.

Beslut hvornår du flytter, og gør status over, hvad du har

Gode grunde til at flytte er gentagne tilfælde af langsom indlæsning eller nedbrud, en plan der ikke længere passer til din trafik, manglende funktioner som en aktuel PHP-version eller staging-værktøjer, dårlig support eller en fornyelsespris, der er steget til mere, end tjenesten er værd. Dårlige grunde er en enkelt dårlig eftermiddag eller et prangende tilbud, du ikke har sammenlignet ordentligt. Hvis du stadig overvejer dine muligheder, gennemgår vores guide til valg af webhosting, hvad du skal kigge efter, og guiden om fornyelsespriser på hosting forklarer, hvorfor prisen efter første periode ofte ændrer sig.

Vælg et roligt tidspunkt til flytningen. For de fleste sider betyder det en hverdagsaften eller en weekend med lav trafik, og aldrig ugen med et stort udsalg, en lancering eller en kampagne. Giv dig selv nogle dages margen, også selvom selve arbejdet kun tager et par timer.

Før du rører noget, skal du skrive ned, hvad din nuværende host gør for dig. Hjemmesider afhænger ofte af ting, som ingen husker at have sat op. Her er en enkel oversigt, du kan udfylde.

Eksportér din nuværende DNS-zone som tekst, eller tag skærmbilleder af alle records. Dette ene skridt forhindrer mere panik efter flytningen end noget andet. Tjek også, om dit domæne og din hosting ligger hos samme firma. Hvis du er usikker på, hvordan de to dele hænger sammen, forklarer domænenavne og hosting forholdet.

Tag backup, byg den nye side og test den privat

Tag en fuld backup af filer og databaser, og gem den et andet sted end hos den gamle host, for eksempel på din egen computer og et ekstra sted. Stol ikke kun på hostens automatiske backups, for du kan miste adgangen til dem, hvis kontoen lukkes. Tjek, at backuppen faktisk kan åbnes. En backup, du aldrig har gendannet, er kun et håb.

Sæt den nye host op

Opret kontoen eller abonnementet, tilføj dit domæne som en side eller et addon-domæne, og vælg den samme store PHP-version, som din side kører på i dag, eller en nyere, du allerede har bekræftet, at din kode understøtter. Opret en tom database og en databasebruger med en stærk adgangskode. Lad være med at ændre DNS endnu. På dette tidspunkt er den nye host bare et tomt rum, der venter på dine møbler.

Kopiér filer og database

Upload dine filer via SFTP eller filhåndteringen i kontrolpanelet. SFTP foretrækkes frem for almindelig FTP, fordi det krypterer dit login. Til en stor side kan du pakke mappen i ét arkiv, uploade det og pakke det ud på serveren, hvilket er langt hurtigere end at sende tusindvis af små filer.

Eksportér derefter din database fra den gamle host, og importér den på den nye. For WordPress er der to almindelige veje. Du kan bruge et migreringsplugin, der pakker filer og database sammen, eller du kan gøre det manuelt: kopiér filerne, importér databasen, og ret derefter filen wp-config.php til det nye databasenavn, den nye bruger og den nye adgangskode. En statisk side kræver kun filerne. En PHP-side med egen kode kræver filerne, databasen og et omhyggeligt kig på alle konfigurationsfiler, der gemmer stier, loginoplysninger eller API-nøgler.

Test før du skifter

Nu skal du tjekke den nye kopi, mens offentligheden stadig ser den gamle. Der er to pålidelige måder at gøre det på.

• Ret din hosts-fil. Tilføj på din egen computer en linje, der kobler dit domænenavn til den nye servers IP-adresse. Din browser henter så den nye kopi, mens alle andre stadig ser den gamle. Fjern linjen, når du er færdig.
• Brug en midlertidig URL. Mange hosts giver en forhåndsvisningsadresse til nye konti. Det er nemmere, men nogle programmer, blandt andet WordPress, kan sende dig tilbage til det rigtige domæne, og derfor er metoden med hosts-filen som regel renere.

Mens du tester, skal du klikke dig gennem forsiden, nogle undersider, søgning, formularer, logins, kassen hvis du har en, og billedgallerier. Send en test via kontaktformularen, og bekræft, at mailen kommer frem. Se efter ødelagte billeder, advarsler om blandet indhold og fejlsider. Sammenlign den nye kopi med den gamle side om side.

Sænk TTL, frys ændringer og skift DNS

DNS er systemet, der oversætter dit domænenavn til en serveradresse. Hver DNS-record har en TTL, forkortelse for time to live, som fortæller andre netværk, hvor længe de må huske svaret, før de spørger igen. Hvis din TTL er et døgn lang, kan nogle besøgende blive ved med at komme til den gamle server i op til et døgn efter, at du har skiftet.

Sænk mindst to dage før flytningen TTL på dine vigtigste records til noget kort, for eksempel fem minutter. Det skal ske i god tid, fordi den gamle lange TTL først skal udløbe overalt. Hvis du sænker den en time før skiftet, gør det kun lidt.

Frys ændringer i indhold

Når din endelige kopi er lavet, skal du stoppe ændringer på den gamle side. En blog kan simpelthen sætte udgivelser på pause. En webshop er sværere, fordi ordrer afgivet på den gamle server efter din sidste databasekopi ikke findes på den nye. For butikker, medlemssider og fora bør du planlægge et kort vedligeholdelsesvindue, tage den sidste databasekopi i starten af det og undgå ordrer i mellemtiden. Lav derefter en sidste synkronisering af filer og database til den nye host, og kør en sidste hurtig test.

Skift records

Du har to måder at lade dit domæne pege på den nye host.

• Ret A-recorden (og AAAA, hvis den bruges) hos din nuværende DNS-udbyder, så den peger på den nye servers IP-adresse. Det lader resten af din DNS, herunder mail, være præcis som den er. Det er den sikreste løsning for de fleste.
• Skift nameservere hos din registrator, så den nye host styrer al DNS. Det er ryddeligt, men gør det kun, efter at du har genskabt alle records fra din oversigt hos den nye host, især MX- og TXT-records. Manglende records er den almindelige årsag til tabt mail efter en flytning.

Hvor lang tid propagering egentlig tager

Folk siger ofte, at DNS tager op til 48 timer, men det er mere en worst case-vane end en regel. Der spreder sig faktisk ikke noget ud fra din DNS-udbyder. I stedet har tusindvis af resolvere verden over hver deres cachede svar, og hver af dem opdaterer det først, når dens timer løber ud. Med en kort TTL, der er sat på forhånd, når de fleste besøgende den nye server inden for minutter til nogle få timer. Skift af nameservere kan tage længere tid, fordi registret har sin egen cache, og nogle internetudbydere holder fast i svar længere, end de burde. Derfor skal den gamle host forblive aktiv under overgangen. Nogle vil se den gamle side, andre den nye, og begge skal virke.

Du kan følge med via offentlige DNS-opslagsværktøjer, der spørger mange steder fra, eller med et opslag på kommandolinjen på din egen maskine. Husk, at din egen computer og router også cacher svar, så en test fra en telefon på mobildata kan give en nyttig second opinion.

Håndtér mail, SSL og URL'er

Mail og MX-records

Mail er den del, der oftest glemmes. Find først ud af, hvor din mail ligger. Hvis den ligger hos din gamle webhost, skal du også flytte postkasserne, inklusive de gemte beskeder. Opret de samme postkasser hos den nye host, og kopiér derefter gammel mail over med et IMAP-overførselsværktøj eller ved at tilføje begge konti i et mailprogram og trække mapperne over. Bliv ved med at sende og modtage på den gamle server, indtil kopieringen er færdig.

MX-records fortæller omverdenen, hvor din mail skal leveres. Hvis du kun ændrer A-recorden, bliver MX urørt, og mailen fortsætter derhen, hvor den går i dag. Hvis du skifter nameservere, skal du kopiere MX-records præcist, plus SPF-, DKIM- og DMARC-TXT-records, som hjælper dine beskeder med at undgå spammapper. Hvis din mail ligger hos en separat mailudbyder, skal du lade dens records være helt i fred. Er du i tvivl, så send testbeskeder i begge retninger samme dag.

SSL-certifikater

En sikker hængelås kræver et gyldigt certifikat på den nye server. De fleste hosts kan udstede et gratis automatisk certifikat, men de kræver som regel, at domænet allerede peger på dem, så udstedelsen lykkes måske først efter DNS-skiftet. Regn med et kort vindue, og bed om certifikatet, så snart records er ændret. Nogle hosts lader dig installere et certifikat på forhånd, hvilket undgår et hul. Når det er aktivt, skal du tjekke, at alle sider indlæses over HTTPS uden advarsler om blandet indhold, og at HTTP-adresser omdirigeres til HTTPS.

Omdirigeringer og URL'er

Hold dine URL'er identiske, hvor det er muligt. Hvis en sides webadresse ændres, skal du tilføje en permanent omdirigering fra den gamle adresse til den nye, så besøgende og søgemaskiner følger med. Tag dine omdirigeringsregler med, som ofte ligger i en skjult fil kaldet .htaccess eller i serverkonfigurationen. Tjek også, at din foretrukne version af domænet, med eller uden www, opfører sig som før. Hvis du også ændrer selve domænenavnet, er det et særskilt projekt, der fortjener sin egen plan.

Overvåg efter skiftet og hav en plan for at rulle tilbage

De første par dage skal du holde nøje øje med siden. Indlæs vigtige sider jævnligt, test formularer og kasse, og se på serverens fejllogs. Opret en gratis oppetidsovervågning, hvis du ikke allerede har en. Bekræft, at planlagte opgaver kører, da cron-jobs er lette at glemme. For WordPress skal du sikre dig, at planlagte indlæg bliver udgivet, og at backupplugins virker. Opret backups igen hos den nye host, og tjek, at dine analyse- og search console-værktøjer stadig rapporterer data.

Din plan for at rulle tilbage er enkel, fordi du har forberedt dig. Den gamle side kører stadig, og dine oprindelige DNS-records er gemt. Hvis noget alvorligt går i stykker og ikke kan rettes hurtigt, skal du sætte records tilbage til de gamle værdier. Takket være den korte TTL spreder tilbageførslen sig også hurtigt. Beslut på forhånd, hvad der tæller som alvorligt, for eksempel at kassen fejler, eller at mail ikke kommer frem, så du ikke skal diskutere det under pres.

Behold det gamle abonnement i en kort overlapning, typisk en til to uger, og længere hvis du er usikker på mailen eller har en månedlig betalingsperiode. Opsig det ikke samme dag. Før du opsiger, skal du tage en sidste backup, bekræfte at der ikke er mail tilbage på det, og tjekke, at intet, for eksempel et subdomæne eller et lille sideprojekt, stadig afhænger af det. Tjek også, om din domæneregistrering var en del af det gamle abonnement, så du ikke ved et uheld mister den.

Almindelige fejl og hvornår du skal have hjælp

• At glemme mail. Mailen stopper, fordi MX- eller TXT-records ikke blev kopieret.
• At lade TTL stå højt. Skiftet trækker så ud i timer eller dage.
• At springe testen over. Problemerne dukker op foran kunderne i stedet for i det private.
• At opsige det gamle abonnement for tidligt. Det fjerner dit sikkerhedsnet, mens DNS stadig falder til ro.
• At redigere begge kopier. Indhold tilføjet på den gamle side under flytningen går tabt.
• At undlade at gemme DNS-records. Du kan ikke genopbygge det, du ikke har skrevet ned.
• At ignorere PHP- og softwareversioner. Et gammelt plugin kan fejle på en nyere serverversion.

Mange hosts tilbyder en gratis flytteservice, som regel til nye kunder, der flytter en standardside. Den er værd at bruge til enkle WordPress-sider, fordi den sparer tid, og eksperterne har gjort det mange gange. Stil nogle spørgsmål først. Dækker den filer, databaser og mail? Hvor mange sider eller postkasser er inkluderet? Vil de teste siden før skiftet, og får du en forhåndsvisning? Bliver den gamle side ladt urørt? Hvem håndterer DNS, og hvad sker der, hvis noget går galt? Er der begrænsninger på størrelse, egen kode eller bestemte programmer? Få svarene skriftligt, hvor du kan.

Overvej betalt professionel hjælp, hvis du driver en webshop med aktive ordrer, et medlems- eller bookingsystem, en stor database, egen kode som ingen på dit team har skrevet, eller komplicerede mailopsætninger. En freelancer eller et bureau kan også være fornuftigt, når nedetid ville koste dig mere end deres honorar. Selv hvis du hyrer nogen, skal du beholde din egen oversigt og dine backups og bevare kontrollen over din domænekonto.

Et eksempel på en tidsplan for flytning

1. En uge før: Beslut at flytte, vælg den nye host, og færdiggør din oversigt over filer, databaser, mail, cron-jobs, DNS og SSL.
2. Tre til fem dage før: Eksportér DNS-zonen, tag fulde backups, og bekræft, at de kan gendannes.
3. Tre dage før: Sænk TTL på dine vigtigste DNS-records til nogle få minutter.
4. To dage før: Sæt den nye host op, kopiér filer og database, og opdatér konfigurationen.
5. En dag før: Test via hosts-filen eller en midlertidig URL, og ret problemer.
6. Skiftedagen, start: Frys ændringer i indhold, lav en sidste synkronisering af filer og database, og kør en hurtig test.
7. Skiftedagen, midt på dagen: Opdatér A-recorden eller nameserverne, og bed derefter om SSL-certifikatet.
8. Samme dag: Tjek, at mail stadig flyder i begge retninger, og bekræft, at HTTPS og omdirigeringer virker.
9. Dag et til tre: Overvåg oppetid, logs, formularer, cron-jobs og analyse. Tø indholdet op, når du er sikker.
10. Dag syv til fjorten: Tag en sidste backup fra det gamle abonnement, bekræft at intet afhænger af det, og opsig det. Sæt TTL tilbage til en normal værdi.

Tjekliste før og efter

Før

• Oversigt nedskrevet: filer, databaser, mail, cron-jobs, DNS-records, SSL.
• DNS-zonen eksporteret og gemt uden for den gamle host.
• Fulde backups taget, gemt to steder og testgendannet.
• TTL sænket mindst to dage før skiftet.
• Ny host sat op med en tilsvarende eller kompatibel PHP-version.
• Filer og database kopieret, konfiguration opdateret.
• Siden testet via hosts-filen eller en midlertidig URL, inklusive formularer og logins.
• Mailplan besluttet, postkasser oprettet, gamle beskeder kopieret.
• Indholdsfrys planlagt og meddelt til alle, der redigerer siden.
• Plan for at rulle tilbage skrevet ned, med de oprindelige DNS-værdier ved hånden.

Efter

• Domænet indlæses fra den nye server på flere netværk og enheder.
• HTTPS virker på alle sider, og HTTP omdirigeres til HTTPS.
• Mail sender og modtager, og SPF-, DKIM- og DMARC-records er på plads.
• Formularer, kasse, søgning og logins virker.
• Omdirigeringer og valget mellem www og uden www opfører sig som før.
• Cron-jobs og planlagte opgaver kører.
• Oppetidsovervågning og backups er aktive hos den nye host.
• TTL sat op igen, når tingene er stabile.
• Gammelt abonnement beholdt i en til to uger og derefter opsagt efter en sidste backup.

En bemærkning om gennemsigtighed: DealPortal kan optjene en provision, hvis du køber via nogle links på vores side, og det ændrer hverken den pris, du betaler, eller de råd, vi giver.

Vigtigste pointer

• Byg og test den nye kopi privat først, med hosts-filen eller en midlertidig URL, mens den gamle side kører videre.
• Sænk din DNS-TTL mindst to dage i forvejen, og gem en kopi af alle DNS-records, før du ændrer noget.
• Behandl mail som sin egen opgave: flyt postkasserne, kopiér MX-, SPF-, DKIM- og DMARC-records, og test i begge retninger.
• Propagering er som regel hurtig med en kort TTL, men nogle besøgende vil se den gamle side et stykke tid, så luk aldrig den gamle ned for tidligt.
• Behold det gamle abonnement i en til to uger, og hav en skriftlig plan for at rulle tilbage klar.
• Brug en gratis flytteservice til enkle sider, og hyr en professionel til butikker, egen kode eller alt, hvor nedetid er dyr.