Flyt din webapp til ny hosting uden nedetid

Du kan flytte hosting uden nedetid hvis den nye server kører og er testet før du ændrer DNS, og hvis du på forhånd har besluttet hvordan databasen flyttes, og hvordan du kommer tilbage. Så bliver selve skiftet et kort, planlagt øjeblik i stedet for en nat med krydsede fingre. Det svære er sjældent koden, men de data der ændrer sig undervejs: ordrer, brugere og uploadede filer.

Jeg er freelanceudvikler og hjælper selv med flytninger som en del af vedligehold, så læs afsnittet om hvornår du ikke behøver en udvikler, med det i baghovedet.

Den korte version: tidsplanen for en flytning

En flytning uden nedetid er mest af alt et spørgsmål om rækkefølge. Alt det der kan gå galt, skal gå galt på den nye server, før nogen kunde bliver sendt derhen.

Beslutningsreglen er enkel. For besøgende der kun læser, kan nedetid næsten altid undgås helt. For data der bliver skrevet, står valget mellem nogle få minutters planlagt skrivepause og en mere kompleks løbende synkronisering. De fleste mindre og mellemstore webapps er bedst tjent med det første.

En hostingflytning hører til den løbende drift og vedligehold af en webapp, og den bliver langt nemmere, når resten af driften allerede er i orden.

Trin 1-3: forberedelsen afgør om flytningen lykkes

Det meste af arbejdet ligger før skiftet. En god forberedelse gør skiftedagen kedelig, og det er netop målet.

1. Kortlæg alt appen afhænger af. Koden er den nemme del. Det der bliver glemt, er alt det rundt om: cronjobs (planlagte opgaver), køer der kører i baggrunden, uploadede filer, miljøvariabler og API-nøgler, SSL-certifikater, PHP-version og backupjobs. Tjek også om en integration kun accepterer kald fra den gamle servers IP-adresse (en IP-whitelist), og om andre systemer sender webhooks til en fast adresse. Ligger din mail hos den gamle udbyder, skal MX- og SPF-records med, ellers holder mailen op med at virke.

2. Byg det nye miljø og test det med rigtige data. Sæt serveren op, læg appen på, og importér en kopi af produktionsdatabasen. Peg din egen computer på den nye server via hosts-filen (en lille fil der overstyrer DNS for netop din maskine), så kan du logge ind og gennemføre et køb på det rigtige domæne, uden at andre bliver sendt derhen. Brug samme PHP- og databaseversion som før. Opdatering af framework og pakker er en opgave for sig, så lav den før eller efter flytningen, ikke samme nat.

3. Sænk TTL i god tid. TTL (time to live) styrer hvor længe netværk må huske hvilken server dit domæne peger på. Står den til et døgn, kan nogle besøgende blive sendt til den gamle server i op til et døgn efter skiftet. Google anbefaler i sin vejledning om at flytte hosting uden at ændre URL'er at sænke TTL mindst en uge før. Min tommelfingerregel er 5 minutter (300 sekunder) omkring skiftet. Lokale DNS-caches kan dog være længere om at opdatere, som Cloudflare nævner i deres dokumentation om TTL.

Databasen: her afgøres det om der bliver nedetid

Filer og kode kan kopieres i ro og mag. Databasen er anderledes, fordi den ændrer sig hele tiden. Kopierer du den mandag og skifter tirsdag, mangler alle ordrer og brugere fra imellem. Der er to gode måder at løse det på.

Kort skrivepause: det enkle og sikre valg

Du sætter appen på pause for ændringer, tager en sidste kopi af databasen, importerer den på den nye server og skifter. I Laravel sker det med php artisan down, der viser en vedligeholdelsesside med statuskode 503. Med tilvalget --secret kan du selv komme forbi via en hemmelig adresse og teste undervejs. Det står i Laravels dokumentation om maintenance mode. Pausen varer så længe eksport, overførsel og import tager. Til en lille eller mellemstor database er det typisk minutter, men det skal måles ved generalprøven og ikke gættes.

Strengt taget er det en kort nedetid. Men den er planlagt, varslet og lagt på et stille tidspunkt, og for de fleste webapps er det et bedre valg end en kompleks løsning der kan gå galt på nye måder.

Løbende synkronisering: når selv minutter er for meget

Har appen brugere døgnet rundt, fx en SaaS med kunder i flere tidszoner, eller er databasen for stor til at flytte på få minutter, kan den nye database følge med den gamle i realtid. Med MySQL hedder det replikering: den gamle server er kilden, og den nye er en kopi der løbende modtager alle ændringer, som beskrevet i MySQLs dokumentation om replikering. PostgreSQL og de fleste managed databasetjenester har tilsvarende muligheder. Ved skiftet venter du til kopien er helt opdateret, gør den til den primære og flytter skrivningerne.

Prisen er mere opsætning og mere at teste. Det er den rigtige løsning til de apps der har brug for det, men overdrevet til en intern platform med 50 brugere der arbejder fra 8 til 16.

Det der ofte bliver glemt ved skiftet

• Uploadede filer. Synkronisér dem flere gange op til skiftet og en sidste gang under skrivepausen, eller flyt dem til en separat fillagringstjeneste før flytningen.
• Den gamle server må ikke blive ved med at skrive. Mens DNS skifter, rammer nogle besøgende stadig den gamle server. Gemmer den data i den gamle database, ender du med to versioner af virkeligheden. Lad den vise vedligeholdelsessiden eller sende trafikken videre til den nye.
• Sessioner og køer. Ligger login-sessioner i filer på serveren, bliver brugerne logget ud ved skiftet. Det er sjældent en katastrofe, men du skal vide det på forhånd. Tøm køen for ventende jobs, før den gamle server stoppes.

Trin 4-7: selve skiftet

Når forberedelsen er i orden, er skiftedagen en liste der skal følges. Det er ikke dagen til gode idéer.

4. Lav en generalprøve. Gennemfør hele proceduren mod et testmiljø med en frisk kopi af data, og tag tid på det. Skriv rækkefølgen ned med klokkeslæt, så ingen skal improvisere. Det er her du opdager at importen tager 40 minutter og ikke 4.

5. Vælg tidspunkt og giv besked. Find det tidspunkt hvor appen har mindst trafik, og giv brugerne besked i god tid, hvis der bliver en skrivepause. Sørg for at den der laver skiftet, har adgang til domæne, DNS og begge servere, før I går i gang.

6. Gennemfør skiftet. Sæt appen i vedligeholdelsestilstand, eller vent til replikeringen er ajour. Tag en sidste backup, synkronisér data og filer, flyt cronjobs, og skift DNS. Sørg til sidst for at den gamle server ikke længere skriver til databasen.

7. Test som en kunde, med det samme. Log ind, opret noget, gennemfør en betaling, nulstil en adgangskode, og tjek at mails kommer frem. Kontrollér at cronjobs, køer, uploads og webhooks virker, og hold øje med fejlloggen de første timer. Mangler du overvågning, er flytningen et godt tidspunkt at få den sat op. Jeg sammenligner mulighederne i oversigten over værktøjer til overvågning af webapps.

Rollback: vejen tilbage du forhåbentlig ikke får brug for

En rollback-plan er ikke pessimisme. Det er den der gør at du tør gennemføre skiftet. Den har tre dele:

• En stopregel. Beslut på forhånd hvad der får dig til at skifte tilbage, fx at login eller betaling fejler og ikke kan rettes inden for 30 minutter. Uden en regel ender man let med at fejlsøge i produktion hele natten.
• En ansvarlig. Én person træffer beslutningen, og det er sjældent udvikleren alene. Hvor længe en fejl må ramme kunderne, er en forretningsbeslutning.
• En teknisk vej tilbage. Med lav TTL kan DNS hurtigt pege på den gamle server igen. Det svære er data der er skrevet på den nye server efter skiftet. Jo hurtigere du opdager et problem, jo mindre skal flyttes tilbage, og derfor er testen i trin 7 det vigtigste kvarter i hele flytningen.

Tag backup lige før og lige efter skiftet, og vær sikker på at den kan gendannes. Hvordan en backup-strategi der holder i praksis ser ud, står i guiden til backup af webapps.

Efter flytningen: lad den gamle server leve lidt endnu

Google anbefaler i samme vejledning at holde den gamle hosting kørende, indtil serverloggen viser at trafikken er nul, og alle brugere og Googlebot får indholdet fra den nye server. Det kan tage dage. Imens er der lidt oprydning:

• Hæv TTL til et normalt niveau igen, når du er sikker på at du bliver.
• Tjek at backups kører på den nye server. Backupjobbet stoppede sammen med den gamle, og det opdager man ofte først, når man skal bruge en backup.
• Peg overvågning og fejlrapportering på den nye server.
• Opdatér dokumentation og password manager med de nye adgange, og fjern de gamle.
• Har appen persondata, kræver GDPR artikel 28 en databehandleraftale med den nye udbyder. Tjek også hvor data og backups fysisk ligger.
• Gem en sidste kopi af den gamle server, før abonnementet opsiges.

Regn med at betale for to hostingaftaler i et par uger. Det er billig forsikring.

Hvornår du ikke behøver en udvikler til flytningen

Ikke alle flytninger kræver en plan som den her. I disse tilfælde kan du ofte klare det selv eller med hjælp fra hostingfirmaet:

• En almindelig WordPress-side eller hjemmeside uden login og ordrer. Flere hostingfirmaer tilbyder at flytte den for dig.
• En statisk side eller en frontend på Vercel eller Netlify, hvor flytningen mest handler om DNS.
• Shopify, Wix og lignende, hvor platformen ejer serveren. Der er kun et domæne at pege et nyt sted hen.

Du har derimod brug for en udvikler, når appen har en database der ændrer sig hele dagen, betalinger, integrationer med IP-whitelist, køer og cronjobs, eller når ingen længere ved præcis hvordan den gamle server er sat op. Det sidste er den største risiko, fordi serveren så skal kortlægges, før den kan genskabes. Har koden nogle år på bagen, kan flytningen være en anledning til at se på modernisering af en ældre PHP-app, men gør det som et separat projekt.

Næste skridt: lav flytteplanen før du opsiger noget

Start med listen over hvad appen afhænger af. Den kan du lave uden at være teknisk, og den viser hurtigt om flytningen er en eftermiddag eller et lille projekt.

Mangler du en der kan lave planen og stå for skiftet, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende webapps. En flytning er ofte et godt tidspunkt at få styr på resten af driften samtidig.

Ofte stillede spørgsmål

Hvor lang tid tager det at flytte en webapp til ny hosting?+

Regn typisk med 1-4 uger i kalendertid fra beslutning til lukket gammel server, selvom selve skiftet ofte tager under en time. En del af ventetiden er bevidst: TTL skal sænkes en uge før, og den gamle server bør køre videre bagefter. Hvor meget arbejde der ligger i perioden, afhænger mest af hvor godt opsætningen er dokumenteret.

Hvad koster det at flytte hosting for en webapp?+

Prisen afhænger mere af appens kompleksitet end af dens størrelse. En veldokumenteret app med en enkel database og få integrationer er en overskuelig opgave, mens løbende synkronisering og en udokumenteret server kræver betydeligt flere timer. Husk også et par ugers dobbelt hosting. Bed om et estimat delt op i kortlægning, opsætning, skift og opfølgning.

Mister jeg min placering i Google, når jeg skifter hosting?+

Nej, ikke hvis dine URL'er er de samme, og siden svarer normalt fra den nye server. Ifølge Google falder crawlhastigheden ofte kort efter skiftet og stiger så igen over de næste dage. Sørg for at verifikationen i Search Console stadig virker, og hold nedetiden kort. Skifter du samtidig domæne eller URL-struktur, er det en større opgave med omdirigeringer.

Skal min mail flyttes med, når jeg skifter hosting?+

Kun hvis din mail ligger hos den hostingudbyder du forlader. Ligger den hos fx Microsoft 365 eller Google Workspace, skal du blot sikre at MX-, SPF- og DKIM-records kommer uændret med, hvis du også flytter DNS. Sender appen mails direkte fra serveren, skal den nye server godkendes i SPF, ellers lander mails i spam. En transaktionel mailtjeneste gør appen uafhængig af serveren.