Realistisk tidslinje for en seniorledet headless WordPress-migrering: en firefasemodell fra kartlegging til finjustering, med variablene som strekker eller komprimerer planen.
NB

Hvor lang tid tar en headless WordPress-migrering i 2026?

4.70 /5 - (9 votes )
Sist verifisert: 1. mai 2026
5min lesetid
Guide
500+ WP-prosjekter

#Hvor lang tid tar en headless WordPress-migrering i 2026?

Seks til seksten uker for typiske oppdrag. Formen er fire faser: kartlegging, scoping, bygging og overgang, finjustering. Variablene som strekker eller komprimerer planen, er katalogstørrelse, antall integrasjoner, URL-bevaring og redaksjonens beredskap, ikke valg av rammeverk.

Denne artikkelen forankres i tjenestepilaren for headless WordPress og hører sammen med beslutningsmatrisen Next.js mot Astro for rammeverkssiden og Cloudflare Workers og WordPress på edge for kjøretidslaget.

#TL;DR

  • Rene redaksjonelle nettsteder under femti sider: fire til seks uker.
  • WooCommerce med opptil noen tusen SKU og standardintegrasjoner: ti til fjorten uker.
  • Flerregion eller flerspråklig med egne integrasjoner: fjorten til seksten uker, av og til lengre.
  • De dyre ukene er scoping (uke en til to) og overgang (siste helg), ikke selve byggingen.
  • Pris er individuell per prosjekt; vi publiserer tidslinjen, ikke prisen.

#De fire fasene i sanntid

Fasene er ikke etiketter på et Gantt-diagram; de tilsvarer ulike arbeidsmoduser som krever ulike folk i rommet.

#Fase 1, kartlegging (uke null til to)

Interessenter, redaksjonen, analyseansvarlig og teknisk kontaktperson sitter gjennom tre til fem økter over en til to uker. Leveransene er en revisjon av innholdsmodellen, en ytelsesbaseline hentet fra det aktive nettstedet (TTFB, TTI, LCP per mal), en oversikt over plugins og integrasjoner og et utkast til SEO-migrasjonskart.

Resultatet av kartleggingen er beslutningsgrunnlag, ikke arkitektur. Teamet som hopper over kartlegging for å “spare tid”, betaler kostnaden tilbake i uke åtte, når en ikke-meldt integrasjon dukker opp og datalaget må redesignes.

#Fase 2, scoping (uke to til tre)

Arkitekturvalg: Astro 5+ eller Next.js 15, valg av rendering per rute, datahentingsmønster (REST eller GraphQL), strategi for cache-invalidering. Omdirigeringskartet signeres her, ikke senere. Den redaksjonelle arbeidsflyten ferdigstilles: forhåndsvisninger, utkast, planlagt publisering, flerforfatterflyt.

Scoping avsluttes med et skriftlig engagement letter og en låst leveranseliste. Det som mangler her, blir en endringsordre i uke ti, som er det dyreste tidspunktet for å forhandle om omfang.

#Fase 3, bygging og overgang (uke tre til tolv)

Byggingen kjører i to-ukers sprinter med en ukentlig demo. Hver demo er på staging, ikke på localhost, slik at teamet ser hvordan den redaksjonelle siden faktisk oppfører seg i den nye stacken. Første sprint er designsystemet og én mal end-to-end; de neste sprintene fordeler seg på maltyper.

Selve overgangen er et vindu på førtiåtte til syttito timer, planlagt bevisst. To mønstre virker: DNS-bytte (renere, tregere tilbakerulling) og reverse-proxy-overgang (raskere tilbakerulling, flere bevegelige deler). Omdirigeringskartet kjøres på edgen, ikke i PHP.

Det parallelle målevinduet kjører en til to uker før overgang. Det fanger regresjoner i sporingstagger, schema-validering og Core Web Vitals før de havner i produksjon.

#Fase 4, finjustering og drift (uke tolv til seksten)

Edge-cache-TTL-er justeres per rute. Observability (Cloudflare Logpush, syntetiske tester, varsling på TTFB og 5xx-rater) kobles på. Overleveringen til drift dekker arbeid med nye funksjoner, kvartalsvise Tech Radar-gjennomganger og en veikart for redaksjonens skiftende behov.

Dette er fasen som oftest hoppes over. Det å hoppe over koster et halvår med småfeil teamet ikke kan diagnostisere fordi ingenting er instrumentert.

#Hva strekker tidslinjen

Tre mønstre dytter et seksukers prosjekt til tolv, og et tolvukers prosjekt til tjue.

Sent oppdagede integrasjoner. En egen betalingsløsning, en gammel ERP-integrasjon over SOAP, en smal tilleggspakke uten REST-grensesnitt. Hver av dem krever en skreddersydd adapter. Hver adapter legger til to til fire ukers bygging, pluss kontraktsforhandling hvis en tredjepart eier oppstrømssystemet.

URL-bevaring. Et nettsted med tretti unike URL-mønstre er mekanisk arbeid. Et nettsted med tre hundre mønstre pluss en restrukturering av permalenker er et eget prosjekt. 301-kartet signeres i scoping, ikke improviseres i uke ti.

Omarbeid av innholdsmodellen. Når det eksisterende WordPress-innholdet er strukturert rundt malene i temaet i stedet for strukturerte felt, kan ikke frontenden forbruke det deterministisk. Å bygge om innholdsmodellen legger til to til seks uker og krever tilgjengelighet fra redaksjonen som de fleste team undervurderer.

#Hva komprimerer tidslinjen

Fire forhold forkorter planen pålitelig.

Ren innholdsmodell. Custom post types, ACF- eller Meta Box-feltgrupper, eller et nylig bytte til blokkredigereren med strukturerte mønstre. Frontenden leser strukturerte data og rendrer deterministisk. Sparer to til fire uker.

Eksisterende designsystem. Et Figma-bibliotek, et tokensett eller et komponentbibliotek teamet har brukt før. Sparer en til to uker grunnarbeid i første sprint.

Tilgjengelig redaksjon. Når redaksjonen kan sitte på forhåndsvisninger ukentlig og signere flyt, stopper ikke byggingen i påvente av avklaring. Sparer en til to uker over hele oppdraget.

Seniorteam på begge sider. En senior product owner på kundesiden halverer spørsmål-svar-syklusen. Byrået kan ikke produsere dette; det må komme fra kjøperen.

#Når seks-ukers-svaret er feil

En WooCommerce-butikk med tre tusen SKU og en egen kasseløsning migrerer ikke på seks uker. Den som tilbyr den tidsplanen, selger en annen scope og reforhandler senere. Det ærlige svaret for denne profilen er tolv til fjorten uker.

Et flerregionsnettsted med fem locales og locale-spesifikke handelsflyter er heller ikke et seksukers prosjekt. Oversettelsesflyt, hreflang-validering, locale-spesifikke cache-strategier og betalingsintegrasjoner per region legger til fire til seks uker selv på en sunn baseline.

#Når seksten-ukers-svaret er feil

Et lite redaksjonelt nettsted, en frisk WordPress-installasjon, en ren innholdsmodell og et seniorteam kan levere på fem uker. Å tilby seksten uker for den profilen er oppblåst scope.

Et greenfield headless-nettsted (uten migrasjonskomponent, bare en ny front på en ny WordPress) hopper over mesteparten av fase én og forkorter fase tre. Seks til åtte uker totalt.

#Slik ser pris ut

Pris er individuell per prosjekt. Vi publiserer ikke tjenestepriser på det offentlige nettstedet. Engagement letteret binder timer til de fire fasene over, med et fast tak på fase én (den er begrenset av antall intervjuer, ikke av noe som skaleres) og time-and-materials eller fixed-scope på fase tre (avhengig av hvor stabilt omfanget er etter scoping).

Vi fakturerer i EUR eller USD, EU-jurisdiksjon, B2B-kontrakt. Se tjenestepilaren for headless WordPress for samarbeidsmodellen.

#Cluster reading

Støtteartiklene i klyngen, etter tema.

Neste steg

Gjor artikkelen om til faktisk implementering

Denne blokken styrker intern lenking og sender leseren videre til de mest relevante tjenestene og innholdet.

Kan en headless WordPress-migrering leveres på under seks uker?
Av og til. Rene redaksjonelle nettsteder under femti sider, uten e-handel og med ren URL-struktur, kan leveres på fire til fem uker. De fleste oppdragene som treffer fireukersmerket, er enten greenfield eller har et ferdig designsystem teamet kan ta i bruk. Flaskehalsen er sjelden frontend-rammeverket; det er innholdsmodellering og forankring hos interessenter.
Hva drar en migrering forbi seksten uker?
Tre ting går igjen. For det første sent oppdagede integrasjoner (gammel ERP, egen betalingsløsning, smale tilleggspakker uten REST-grensesnitt) som krever skreddersydde adaptere. For det andre URL-endringer som tvinger fram et 301-kart over tusenvis av sider. For det tredje en innholdsmodell som må bygges om før frontenden kan bygges deterministisk. Hvert enkelt punkt legger til to til fire uker; alle tre legger til åtte eller mer.
Endrer valget av Astro eller Next.js tidslinjen?
Marginalt. Begge leverer en full headless front på lik tidsbruk for et seniorteam. Astro leverer typisk innholdsnettsteder en uke raskere fordi statisk er standardvalget. Next.js leverer personalisert handel en uke raskere fordi App Router og React Server Components er trimmet for det. Rammeverksvalget er en passforms-beslutning, ikke en tempo-beslutning.
Hvor lang er kartleggingsfasen?
En til to uker for et typisk oppdrag. Intervjuer med interessenter, revisjon av innholdsmodellen, ytelsesbaseline, oversikt over plugins og integrasjoner og et utkast til SEO-migrasjonskart. Å hoppe over eller forkorte kartleggingen er den vanligste årsaken til omarbeid i uke åtte.
Hvor stort er risikovinduet ved overgang?
Førtiåtte til syttito timer etter DNS- eller proxy-bytte. Risikoen ligger i utdaterte cacher, glemte omdirigeringer og regresjoner i sporingstagger. Vi demper med et parallelt målevindu, et innøvd omdirigeringskart og syntetiske tester mot den nye originen før overgangen, ikke etter.

Trenger du FAQ tilpasset bransje og marked? Vi lager en versjon som støtter dine forretningsmål.

Ta kontakt

Relaterte artikler

Cloudflare Workers kjører JavaScript og WebAssembly i hundrevis av datasentre i over 100 land verden over. Å sette Workers foran en WordPress-origin flytter lese-stien bort fra WordPress-serveren og gjør WooCommerce til en edge-rendret butikk. Slik fungerer arkitekturen, der den ryker, og hva som bør måles før innføring.
wordpress

Cloudflare Workers og WordPress: WooCommerce levert fra edge

Cloudflare Workers kjører JavaScript og WebAssembly i hundrevis av datasentre i over 100 land verden over. Å sette Workers foran en WordPress-origin flytter lese-stien bort fra WordPress-serveren og gjør WooCommerce til en edge-rendret butikk. Slik fungerer arkitekturen, der den ryker, og hva som bør måles før innføring.

Next.js og Astro ligger begge i Adopt-ringen i vår Tech Radar Q3 2026. Å velge mellom dem til en headless WordPress-front er ikke et smaksspørsmål. Det er et spørsmål om interaktivt overflateareal, byggekostnad og hvilket arbeidsmarked du befinner deg i.
wordpress

Headless WordPress, Next.js mot Astro 2026: en senioringeniørs beslutningsmatrise

Next.js og Astro ligger begge i Adopt-ringen i vår Tech Radar Q3 2026. Å velge mellom dem til en headless WordPress-front er ikke et smaksspørsmål. Det er et spørsmål om interaktivt overflateareal, byggekostnad og hvilket arbeidsmarked du befinner deg i.

Migrer fra Shopify til WooCommerce uten a miste data, kunder eller SEO-rangeringer. Dekker produktoverforing, 301-omdirigeringer, URL-kartlegging, WP-CLI-automatisering og sjekkliste etter migrering.
wordpress

Migrering fra Shopify til WooCommerce: den komplette steg-for-steg-guiden

Migrer fra Shopify til WooCommerce uten a miste data, kunder eller SEO-rangeringer. Dekker produktoverforing, 301-omdirigeringer, URL-kartlegging, WP-CLI-automatisering og sjekkliste etter migrering.