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

#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. Alle ukeintervallene i denne artikkelen er anslag fra vår egen prosjektpraksis, ikke en markedsundersøkelse; den bindende tidsplanen settes etter kartleggingen.

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.

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.

#Hvordan eksponere innholdstyper og felt i REST API og WPGraphQL

Raden om ACF-felt i tabellen over har en konkret teknisk årsak. En custom post type vises ikke i REST API før den registreres med show_in_rest => true. Det argumentet legger til en rute i navnerommet wp/v2, og URL-segmentet får som standard navnet på typen hvis rest_base ikke er satt (WordPress sin REST API-håndbok). Taksonomier trenger det samme argumentet i register_taxonomy.

WPGraphQL har sin egen bryter. En innholdstype kommer inn i GraphQL-skjemaet når show_in_graphql og graphql_single_name (camel case, uten mellomrom, starter med en bokstav) er satt. graphql_plural_name er valgfritt; uten det får listefeltet prefikset all (WPGraphQL-dokumentasjonen). Den samme dokumentasjonen beskriver en felle som er typisk for headless: anonyme forespørsler returnerer publiserte oppføringer bare når public eller publicly_queryable er true. En type som er registrert som ikke-offentlig fordi temaet ikke har noen mal for den, returnerer data bare til brukere med redigeringsrett. Dokumentasjonen anbefaler da å sette publicly_queryable => true eksplisitt.

Derfor bør inventaret fra kartleggingen notere tre verdier for hver innholdstype: show_in_rest, show_in_graphql og publicly_queryable. Mangler én, er endringen i registreringskoden, ikke i frontenden.

#Hvordan lage et 301-kart for en headless-migrering

Google behandler endrede URL-er som en flytting av nettstedet og anbefaler permanente omdirigeringer på serversiden (301 eller 308) fra hver gammel URL til motstykket, etter en kartlegging laget før flyttingen. Den samme dokumentasjonen advarer mot å sende mange gamle URL-er til én urelatert side, for eksempel forsiden. Omdirigeringene bør stå så lenge som mulig, som regel minst ett år. For mellomstore nettsteder kan det ta Google noen uker eller mer å vise de nye URL-ene i stedet for de gamle, og synligheten i søk kan svinge i mellomtiden (Google Search Central om flytting av nettsted med endrede URL-er).

Når kartet legges på edgen, teller plattformens grense. Filen _redirects i Cloudflare Pages tar opptil 2000 statiske og 100 dynamiske omdirigeringer, 2100 totalt, og hver regel kan ha høyst 1000 tegn. Større kart går til Bulk Redirects (Cloudflare Pages-dokumentasjonen). Derfor former antallet URL-mønstre fra kartleggingen arkitekturen: tretti mønstre får plass som dynamiske regler innenfor grensen, mens tusenvis av enkelt-URL-er uten felles mønster trenger en annen mekanisme.

#SSG, ISR eller SSR og hvordan rendering påvirker publisering

Scopingen velger rendering per rute, og det valget avgjør når en endring lagret i WordPress-panelet vises på nettstedet. Astro forhåndsrendrer sider, ruter og endepunkter ved bygging som standard. En enkelt side går over til rendering ved forespørsel med export const prerender = false, og output: 'server' snur standarden for hele prosjektet. Begge deler krever en serveradapter (Astro-dokumentasjonen). I en rent statisk variant betyr hver publisering et nytt bygg, så redaksjonsflyten trenger en byggutløser når et innlegg lagres.

Next.js har Incremental Static Regeneration. Eksporten revalidate setter tiden etter hvilken neste forespørsel starter regenerering av siden i bakgrunnen, og revalidatePath og revalidateTag ugyldiggjør cachen ved behov, for eksempel fra en webhook som utløses ved publisering. Dokumentasjonen lister begrensningene: ISR virker ikke med statisk eksport, støtten i adaptere avhenger av plattformen, og med flere instanser er standardcachen per instans, så en ugyldiggjøring når bare instansen som mottok kallet, med mindre en felles cache handler er satt opp (Next.js-veiledningen om ISR).

Forhåndsvisning av utkast henger sammen med dette. For autentiserte REST-forespørsler har WordPress siden versjon 5.6 tilbudt applikasjonspassord: de virker over HTTP Basic, er som standard bare aktive på nettsteder med HTTPS og kan ikke brukes til å logge inn i wp-admin (integrasjonsveiledningen for applikasjonspassord). Derfor avtales forhåndsvisning og planlagt publisering i scopingen sammen med renderingen, ikke på slutten av byggingen.

#Relaterte artikler

Støtteartiklene i klyngen, etter tema.

• Cloudflare Workers og WordPress på edge om kjøretidslaget i den nye stacken.