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

Mariusz Szatkowski

Sist verifisert: 22. september 2026

8 min 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.

#Hvilke faser har en headless WordPress-migrering?

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 forsinker en headless WordPress-migrering

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.

#Hvordan få en headless WordPress-migrering til å gå raskere?

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.

#Hvor lang tid tar headless WooCommerce-migrering

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.

#Hvor lang tid tar et lite headless WordPress-nettsted?

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.

#Hvilke WordPress-funksjoner mister du med headless?

Et klassisk WordPress-tema gjør mye arbeid som ingen skriver inn i kravspesifikasjonen. Når temaet kobles fra, forsvinner det arbeidet. Hver bit må enten bygges på nytt i frontenden eller droppes med vilje, og begge deler må stå i estimatet.

Funksjon i dag	Hva skjer i headless	Spørsmål før estimat
Forhåndsvisning av utkast	Finnes ikke ut av boksen	Hvor mange i redaksjonen bruker forhåndsvisning daglig?
Skjemaer (Gravity Forms, Contact Form 7)	Skjemaet rendres ikke lenger	Hvor lagres innsendinger, og hvem mottar dem?
Søk (`?s=`)	Søkeresultatsiden forsvinner	Holder et REST-søk, eller trengs en egen indeks?
Shortcodes i innhold	Kommer ut som rå tekst	Hvor mange innlegg inneholder dem?
ACF flexible content	Hver layout blir en komponent	Hvor mange layouter er faktisk i bruk?
Omdirigeringer (Redirection-tillegget)	Må flyttes til edgen	Finnes det i tillegg regler i `.htaccess`?
Kommentarer	Trenger eget endepunkt eller fjernes	Brukes kommentarfeltet i det hele tatt?

Spørsmålene i siste kolonne skal ha svar før scoping starter. Et spørsmål som står åpent etter kartleggingen, kommer tilbake som en endringsordre i fase tre.

To forhold gjelder spesielt for norske nettsteder. Det første er kassen: Vipps som betalingsmetode og frakt med Bring eller Posten er vanlig i norske WooCommerce-butikker, og tilleggene for dem er skrevet for en kasse som rendres av WooCommerce. En headless kasse betyr at integrasjonen må verifiseres mot leverandørens API, ikke mot tilleggets PHP-kode, og det arbeidet hører hjemme i kartleggingen.

Det andre er universell utforming. Private virksomheter i Norge har krav om universelt utformede nettløsninger, og Uutilsynet fører tilsyn. En ny frontend er en ny løsning: menyer, skjemaer og fokushåndtering bygges fra bunnen av, så WCAG-kontrollen må inn i hver sprint og ikke vente til etter lansering.

#Hva koster en headless WordPress-migrering

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.

#Hvordan forberede en headless WordPress-migrering?

Flere av ukene som strekker planen, kan kjøperen korte ned før første økt. Lag en liste over alle integrasjoner, også de små: betalingsløsning, ERP, nyhetsbrev og tilleggspakker uten REST-grensesnitt. Hver integrasjon som dukker opp sent, krever en egen adapter og legger to til fire uker til byggingen. Tell URL-mønstrene på dagens nettsted og noter om permalenkene skal endres, for forskjellen mellom tretti og tre hundre mønstre avgjør om 301-kartet er mekanisk arbeid eller et eget prosjekt.

Sjekk også hvordan innholdet er lagret. Ligger det i custom post types og ACF- eller Meta Box-felt, kan frontenden lese det direkte. Er det bygget rundt temaets maler, må innholdsmodellen bygges om, og det legger til to til seks uker. Avklar til slutt hvem i redaksjonen som kan sitte på ukentlige forhåndsvisninger, og hvem på deres side som kan ta beslutninger raskt. Tilgjengelig redaksjon sparer en til to uker over hele oppdraget, og en senior product owner på kundesiden halverer spørsmål-svar-syklusen.