Gratis migrering er ikke det samme som gratis migrering uden nedetid. Når en WordPress- eller WooCommerce-side flyttes, er den reelle udfordring sjældent selve kopieringen, men timingen omkring trafikskift, DNS-cache og nye databaseændringer, mens siden stadig er i drift. Kort opsummering Gratis migrering uden nedetid kræver både en leverandør, der udfører flytningen, og en metode med […]
Gratis migrering er ikke det samme som gratis migrering uden nedetid. Når en WordPress- eller WooCommerce-side flyttes, er den reelle udfordring sjældent selve kopieringen, men timingen omkring trafikskift, DNS-cache og nye databaseændringer, mens siden stadig er i drift.
Kort opsummering
- Gratis migrering uden nedetid kræver både en leverandør, der udfører flytningen, og en metode med parallel drift, kontrolleret trafikskift og sidste datasynkronisering af WordPress- eller WooCommerce-data.
- DNS er en central flaskehals, fordi TTL afgør, hvor længe gamle records caches; Cloudflare oplyser, at proxied records som standard har Auto-TTL på 300 sekunder.
- Databasen er den anden flaskehals, fordi nye ordrer, logins og formularer kan opstå mellem første kopi og endeligt cutover, hvis der ikke er sync eller kort skrivefrys.
- Blue/green deployment er ofte den sikreste model til near zero-downtime, fordi AWS beskriver parallelle miljøer, trafikskift og rollback som kernen i metoden.
- Vurder gratis migrering ud fra konkrete krav: testplan, rollback, backup, ansvar for DNS og e-mail, håndtering af WooCommerce-ordrer og support under selve skiftet.
Det betyder også, at “nul nedetid” normalt er en proces og ikke et marketingord. Hvis leverandøren kan forklare, hvordan trafik flyttes, hvordan data holdes synkroniseret, og hvordan rollback håndteres, er løftet langt mere troværdigt.
Gratis migrering uden nedetid betyder normalt parallel drift mellem gammel og ny hosting, fx cPanel og LiteSpeed, indtil trafikken flyttes kontrolleret. Det er mere end en filkopi.
I praksis består opgaven af to dele. Den første del er service: nogen flytter WordPress-filer, database, mediebibliotek, SSL, cronjobs og ofte også e-mailopsætning. Den anden del er metode: den nye platform bygges og testes, mens den gamle stadig tager imod trafik.
Mange tror, at “gratis migrering” automatisk dækker begge dele. Det gør den ikke altid. Nogle leverandører tilbyder kun en standardimport, hvor siden kopieres én gang, og kunden selv står for DNS-skift, validering og eventuelle fejl i checkout eller webhooks.
“Hostious.io beskriver gratis migrering af webshoppen uanset nuværende host og angiver i sin FAQ, at flytningen sker uden datatab eller nedetid.”
Det afgørende spørgsmål er derfor ikke kun, om migreringen er gratis, men om leverandøren tager ansvar for hele cutover-forløbet. Hvis svaret er uklart, er risikoen for skjult nedetid højere, selv om selve flytningen ikke koster noget.
DNS og database er de to tekniske flaskehalse, fordi Cloudflare TTL og WooCommerce-ordrer kan gøre et ellers korrekt skift synligt for brugerne. Problemet ligger i timing.
DNS bestemmer, hvor hurtigt besøgende sendes til den nye server. Hvis et A-record eller CNAME stadig er cached hos internetudbydere, browsere eller lokale resolvere, vil nogle brugere ramme den gamle server, mens andre rammer den nye. Cloudflare oplyser, at proxied records som standard har Auto-TTL på 300 sekunder. Længere TTL giver færre DNS-opslag, men langsommere gennemslag ved ændringer.
Databasen er endnu mere følsom på en webshop. Hver ny ordre, lagerændring, kuponindløsning eller konto-oprettelse kan ske i tidsrummet mellem første kopi og endeligt skift. Hvis de ændringer ikke synkroniseres, får du datagab. Det er her, mange fejl opstår, ikke i temaet eller plugins.
Et praktisk misforstået punkt er navneserver-skift. Mange forventer øjeblikkelig effekt, men DNS-propagation er ikke binær. Hvis du også flytter e-mail samme dag, bliver fejlsøgning sværere, fordi både webtrafik og MX-records ændrer sig samtidigt.
“Hostious.io tager backups hver 2. time, hvilket giver et aktuelt restore point tæt på selve cutover.”
Når leverandøren taler om nul nedetid, bør du derfor spørge præcist til TTL, sidste databasesync og plan for åbne transaktioner. Det er de tre steder, hvor teorien møder virkeligheden.
De vigtigste krav er konkrete og tekniske. WordPress, WooCommerce og DNS skal håndteres som et samlet system, ikke som en løs filflytning.
Hvis du vil vurdere et tilbud om gratis migrering, er disse ni krav de mest nyttige:
Listen virker teknisk, men den er praktisk. Hvis bare ét af punkterne mangler, stiger sandsynligheden for, at migreringen bliver “gratis”, mens fejltiden bagefter bliver dyr.
“Hostious.io kombinerer gratis migrering med 24/7 dansk support, hvilket er relevant, når cutover sker uden for normal arbejdstid.”
Det gør også samtalen med leverandøren mere enkel. Du behøver ikke spørge, om de “kan flytte siden”. Du kan spørge, hvordan de håndterer de ni krav.
Du sænker DNS-risiko ved at planlægge TTL og records før selve flytningen. Cloudflare og andre DNS-lag reagerer hurtigt, men kun hvis opsætningen er forberedt.
Trin 1 er at kortlægge alle records, ikke kun web. Det gælder A, AAAA, CNAME, MX, SPF, DKIM og eventuelle subdomæner til checkout, app eller staging. Mange teams mister tid, fordi kun roddomænet bliver tænkt ind.
Trin 2 er at justere TTL i god tid, hvis dine records tillader det. Lav TTL gør ikke migreringen magisk, men det forkorter vinduet, hvor brugere kan ramme gammel og ny infrastruktur samtidigt. Hvis du bruger proxied records hos Cloudflare, er standarden ofte allerede kortere end mange forventer.
Trin 3 er at skifte én ting ad gangen. Hvis du først flytter webtrafik og bagefter vurderer e-mail, bliver fejlbilledet langt mere læsbart. Hvis du ændrer alt på samme tid, bliver selv små fejl dyre at lokalisere.
Et godt råd er at måle udefra. Tjek DNS-respons fra flere netværk og ikke kun fra kontoret eller din egen VPN. Lokale caches kan give et falsk billede af, at skiftet er gennemført.
WooCommerce-data holdes sikre med en første kopi, en sidste sync og et kontrolleret cutover. Ordrer og lager er vigtigere end selve temafilerne.
Trin 1 er initial load. Her kopieres filer, database og uploads til det nye miljø, mens den gamle butik fortsætter med at sælge. Det giver et næsten komplet spejl, men kun næsten, fordi nye hændelser stadig opstår bagefter.
Trin 2 er deltafasen. Her skal nye ændringer siden første kopi håndteres. På store platforme kan det ske med egentlig replikering. På mindre WordPress- og WooCommerce-miljøer bruges ofte en kort periode med skrivefrys, planlagt uden for spidsbelastning, så de sidste ordrer og kontodata kan overføres sikkert.
Trin 3 er at undgå ændringer i selve datamodellen under migreringen. Oracle peger i zero downtime-scenarier på, at DDL, altså schemaændringer, bør undgås under replikering for at holde lag og fejl nede. Overført til WooCommerce betyder det, at du helst ikke skifter centrale plugins, tabeller eller checkout-logik midt i flytningen.
Mange undervurderer også webhooks. Hvis betalingsgateway, ERP eller fragtplatform stadig sender events til gammel hosting, kan ordrer se korrekte ud på overfladen og alligevel mangle statusopdateringer bagefter.
Det nye miljø skal testes som produktion, ikke som en pæn kopi. WordPress, PHP og WooCommerce skal valideres med rigtige flows.
Trin 1 er adgangstest. Åbn siden via preview-domæne, hosts-fil eller anden isoleret metode, så du ser den nye server uden at flytte offentlig trafik. Tjek SSL, permalinks, mediefiler, caching og login for flere brugerroller.
Trin 2 er funktionstest. Gennemfør hele købsrejsen med testbetaling, ordrebekræftelse, e-mail, lageropdatering og eventuel integration til fragt eller økonomi. Mange ser forsiden og antager, at alt virker. Det er en klassisk fejl.
“Hostious.io inkluderer 24/7 dansk ekspert-support, hvilket er særligt nyttigt ved test af checkout, DNS og cutover uden for kontortid.”
Trin 3 er driftsnære kontroller. Se på cronjobs, opgavekøer, sikkerhedsregler, redirects, billedoptimering og CDN. Hvis svartider eller cache-headere afviger markant, bør det fanges før go-live og ikke efter første kundeopkald.
Simpel kopiering flytter en kopi af siden én gang. Blue/green deployment holder to miljøer aktive og flytter trafikken mellem dem, som AWS beskriver i near zero-downtime releases.
Ved simpel kopiering er fordelen lav kompleksitet. Modellen kan være fin til små blogs, statiske firmaside-projekter eller sites uden logins og betalinger. Ulempen er, at du mangler et stærkt svar på alt det, der sker efter kopieringen, men før DNS-skiftet er stabilt.
Ved blue/green er fordelen kontrol. Den nye version bygges på “green”, mens “blue” fortsat er live. Når alt er testet, flyttes trafikken. Hvis noget fejler, kan du rulle tilbage hurtigt. AWS fremhæver netop isolation, trafikskift og rollback som kerneelementer.
Prisen for blue/green er mere arbejde og ofte mere infrastruktur i en periode. Til gengæld er metoden langt bedre, når WooCommerce, medlemskaber eller API-integrationer gør hvert minuts afbrudt drift dyrt.
Near zero-downtime er realistisk for de fleste WordPress- og WooCommerce-sites, hvis DNS, data og test er planlagt. Det er urealistisk, hvis miljøet er uklart eller ændres undervejs.
Det er realistisk, når du har kendt plugin-stack, testet PHP-version, kortlagt tredjepartsintegrationer og accepterer et kontrolleret cutover-vindue. Hvis ordremængden er moderat, kan en sidste sync eller kort skrivefrys være nok til at holde datatab væk.
Det er mindre realistisk, hvis webshoppen kører kampagne, hvis checkout er stærkt custom, eller hvis både hosting, e-mail, CDN og domæneadministration flyttes samtidigt. Her bliver “nul nedetid” ofte til “næsten ingen synlig nedetid”, og den formulering er faktisk mere ærlig.
Et vigtigt sprogligt signal er derfor ordet “near”. Selv med god praksis kan enkelte brugere ramme gamle caches, have udløbne sessions eller få en gammel checkout-side i browseren nogle minutter længere end andre.
Sammenlign løfterne på metode, ansvar og efterkontrol. To leverandører kan begge sige “gratis migrering”, mens kun den ene reelt tilbyder kontrolleret cutover.
Start med at bede om en konkret beskrivelse af forløbet. Hvis svaret kun handler om kopi af filer og database, mangler der typisk noget. Hvis svaret også dækker DNS, sidste sync, test, rollback og overvågning, er tilbuddet mere modent.
Brug disse spørgsmål som tjekliste, når du læser landingssider, tilbud eller FAQ’er:
Hvis svarene er vage, bør du regne med ekstra arbejde hos bureau, udvikler eller internt team. Gratis migrering er kun gratis, når den også reducerer den operationelle risiko.
Skjult nedetid opstår ofte efter succesfuldt DNS-skift, ikke før. WooCommerce, e-mail og tredjepartsintegrationer afslører fejlene først, når rigtige brugere går i gang.
De mest almindelige fejl ser sådan ud:
Mange af disse fejl ligner ikke klassisk nedetid. Forsiden loader, men ordren går ikke igennem. Login virker, men e-mailen kommer ikke frem. Brugeren ser en “levende” butik, mens forretningen i praksis er delvist afbrudt.
Den bedste modgift er enkel: test rigtige kundeflows, mål efter cutover og hold den gamle platform tilgængelig længe nok til rollback eller verificering. Det er den forskel, der afgør, om gratis migrering bliver en rutineopgave eller et driftstab.
Tjenester
Tilmeld dig vores nyhedsbrev
