Flyt et kundesite uden nedetid – og uden at kunden opdager det

Kort svar: En kundesite-flytning uden nedetid er mest proces og lidt teknik: Varsl kunden og vælg et vindue med lav trafik, aftal en kort indholdsfrys, kopiér sitet og test det på en midlertidig adresse, sænk DNS-TTL i god tid, skift DNS på det aftalte tidspunkt – og overvåg begge miljøer, til trafikken er flyttet. „Uden at kunden opdager det“ betyder ikke hemmeligholdelse; kunden skal altid informeres. Det betyder, at hverken besøgende, ordrer eller placeringer i søgeresultaterne mærker noget.

Fagligt gennemgået: 2. oktober 2026

At flytte sit eget site er håndværk. At flytte en kundes site er håndværk plus ansvar plus kommunikation. Går det godt, lægger ingen mærke til noget – går det skidt, ringer kundens kunder til kunden, og kunden ringer til dig.

Selve teknikken er beskrevet i detaljer i guiden om at flytte en WordPress-hjemmeside til ny hosting. Denne artikel handler om bureauprocessen udenom: planlægningen, kommunikationen og de faldgruber, der er særlige for kundesites.

Før du ændrer noget: Sørg for, at du har adgang til domænets DNS (eller ved, hvem der har), en frisk fuld backup af filer og database, og at det gamle miljø ikke opsiges, før det nye har kørt stabilt i mindst en uge.

1. Kortlæg sitet før flytningen

Mange flytninger går galt på noget, ingen vidste, sitet brugte. Lav en kort kortlægning, før du planlægger datoen:

• DNS: Hvor ligger DNS, hvem har adgang, og hvilke records findes der ud over webserveren – MX, SPF, DKIM, verifikations-TXT og subdomæner?
• Mail: Ligger kundens mail på samme hosting som sitet? I så fald skal den håndteres for sig.
• Integrationer: betalingsgateway, fragtplatform, regnskabssystem, nyhedsbrev og webhooks, der peger på sitet.
• Serverafhængigheder: cronjobs, PHP-version og -udvidelser, særlige .htaccess-regler og upload-grænser.
• Adgange: admin-brugere, SFTP og eventuelle IP-hvidlister hos tredjeparter, der skal opdateres med den nye servers IP.

Skriv det ind i sitets dokumentation – den bliver din tjekliste på flyttedagen.

2. Planen og varslingen

Send kunden én mail, før noget sker. Den skal svare på fire ting:

1. Hvorfor der flyttes – fx hastighed, sikkerhed eller samling af driften.
2. Hvornår – dato og tidsvindue, typisk tidlig morgen eller sen aften på en stille ugedag. Kig i sitets statistik, ikke i din kalender.
3. Hvad kunden skal gøre – typisk ingenting, bortset fra en kort indholdsfrys: „opret ikke nye sider eller produkter mellem kl. X og Y“.
4. Hvad der sker, hvis noget driller – du kan pege tilbage til det gamle miljø, som først opsiges efter en succesfuld uge på det nye.

Flytter du en hel portefølje, så flyt én kunde ad gangen – og start med den mest tålmodige, ikke den største.

3. Teknikken – kort version

Kort fortalt:

1. Tag en fuld kopi af filer og database til det nye miljø.
2. Test grundigt på en midlertidig adresse eller via din lokale hosts-fil: forside, formularer, checkout og login – samme minimumstest som i jeres ændringsproces med staging.
3. Sænk TTL i god tid før skiftet.
4. Skift DNS på det aftalte tidspunkt, og lad begge miljøer køre parallelt, mens resolverne rundt om i verden følger med (se DNS ændring ved migrering).

Med hosts-filen kan du se det nye miljø under det rigtige domæne, før DNS ændres. Et eksempel (IP-adressen er et pladsholder-eksempel):

# /etc/hosts på Mac/Linux – C:\Windows\System32\drivers\etc\hosts på Windows
203.0.113.10  kundesite.dk www.kundesite.dk

Husk at fjerne linjen igen bagefter, ellers ser du fortsat det nye miljø, uanset hvad DNS siger.

4. Hvor nedetiden typisk opstår

Nedetid ved en planlagt flytning opstår stort set kun nogle få steder:

Faldgrube	Konsekvens	Forebyggelse
TTL ikke sænket	Skiftet tager timer i stedet for minutter	Sænk TTL mindst et døgn før (eller mindst lige så længe som den gamle TTL)
SSL ikke klar på det nye miljø	Advarsel om usikker forbindelse efter skiftet	Udsted og test certifikatet før DNS-skiftet
Mail og web flyttet samtidig uden styr på MX	Mails afvises eller forsvinder	Flyt mail og web hver for sig
Glemt integration eller IP-hvidliste	Betalinger, fragt eller API-kald fejler	Kortlægning før flytningen (trin 1)
Cache eller CDN peger på gammel origin	Besøgende ser gammelt indhold eller fejl	Opdatér origin og ryd cachen ved skiftet

5. Webshops: ordrevinduet

På en webshop er databasen levende: Hver ordre, der lander på det gamle miljø efter kopien, mangler på det nye. Løsningen er et kort, varslet ordrevindue:

• Tag den endelige databasekopi lige før skiftet.
• Skift DNS med lav TTL.
• Sæt det gamle miljø i vedligeholdelsestilstand, så der ikke kan oprettes nye ordrer dér – eller sammenkør de få mellemliggende ordrer manuelt bagefter ved at sammenligne ordrelister og ordrenumre fra begge miljøer.

Betalingsgatewayens callbacks og webhooks skal pege på den rigtige adresse. Detaljerne står i WooCommerce migrering uden tab af salg.

Læg vinduet dér, hvor shoppen faktisk sover: om natten for de fleste – men ikke nødvendigvis for en shop med B2B-ordrer fra udlandet om natten.

6. Efter flytningen

Når DNS peger rigtigt:

• Kør tjeklisten efter flytningen: formularer, mails fra sitet, betalinger, redirects og Search Console.
• Sæt overvågning på det nye miljø fra første minut.
• Hold det gamle miljø kørende en uges tid som sikkerhedsnet.

Meld så tilbage til kunden med før- og efter-tal – fx indlæsningstid målt på samme måde før og efter – så flytningen ikke bare var „noget teknisk“, men en synlig forbedring. Målingen hører naturligt hjemme i næste månedsrapport.

7. Gør flytningen til et produkt

Bureauer, der kan flytte sites uden dramatik, kan også vinde sites: „Vi flytter jer uden nedetid“ er et stærkt tilbud i salgssamtaler med kunder, der er utilfredse hos en anden leverandør. Gør processen til en fast pakke med tjekliste og faste vinduer.

Læg fundamentet rigtigt. Flytter du kunderne til bureau-hosting hos Hostious, kan Hostious’ gratis migrering klare selve flyttearbejdet – så din rolle er planen, kommunikationen og efter-tjekket.

Kør en generalprøve, første gang du bruger processen – gerne på dit eget site. Tag tid på hvert trin, afprøv tilbagerulning (peg DNS tilbage – virker alt så?), og notér, hvor tjeklisten haltede. En times øvelse gør den første rigtige kundeflytning rolig i stedet for improviseret og giver dig realistiske tidsangivelser til varslingsmailen.

Læs også

• Hub: For bureauer og freelancere
• Sådan flytter du en WordPress-hjemmeside til ny hosting
• WooCommerce migrering uden tab af salg
• Efter flytningen: tjeklisten, der fanger alt det glemte
• TTL forklaret: sæt den rigtigt før ændringer
• Gratis migrering – Hostious flytter dit WordPress-site for dig

Ofte stillede spørgsmål om at flytte et kundesite

Skal jeg fortælle kunden, at sitet flyttes?

Altid – det er deres site og deres forretning. „Uden at kunden opdager det“ handler om driften: ingen nedetid, ingen tabte ordrer og ingen overraskelser.

Hvor lang tid før skiftet skal TTL sænkes?

Mindst lige så længe før som den nuværende TTL – i praksis ofte et døgn – så den gamle, høje værdi er udløbet i resolvernes cache. Sænk fx til 300 sekunder, så slår skiftet igennem på minutter for de fleste.

Hvornår må det gamle miljø opsiges?

Tidligst efter en succesfuld uge på det nye miljø, når overvågning, formularer, betalinger og søgetrafik er bekræftet i orden. Det gamle miljø er dit sikkerhedsnet, hvis du skal rulle tilbage.

Hvordan undgår jeg at miste ordrer, når en webshop flyttes?

Tag den endelige databasekopi lige før DNS-skiftet, og spær for nye ordrer på det gamle miljø i overgangen – eller sammenlign ordrelisterne fra begge miljøer bagefter og overfør de få mellemliggende ordrer manuelt.