WordPress naar Statamic: hoe je page builder de migratiekosten bepaalt
De meeste handleidingen voor "WordPress naar Statamic migreren" gaan ervan uit dat je een kale Gutenberg-installatie hebt. Echte zakelijke sites draaien op ACF, Elementor, Divi of WPBakery — en die keuze bepaalt de migratiekosten meer dan welke andere factor ook. Hier lees je hoe je je situatie herkent en wat je moet vragen voordat je tekent.
Om er getallen achter te zetten: Advanced Custom Fields draait op meer dan 2 miljoen WordPress-sites, en Elementor op meer dan 10 miljoen (volgens de WordPress.org plugin directory), met Divi en WPBakery die de visual-builder-laag eronder invullen. De pluginlaag die je van buitenaf niet ziet, is wat het grootste deel van de migratierekening bepaalt.
Dit stuk legt uit hoe je herkent wat je daadwerkelijk hebt, wat elk archetype kost om te migreren, waar de rekeningen verstopt zitten, en wat je moet vragen voordat je een scope tekent. Het is voor eigenaren en beslissers, niet voor ontwikkelaars.
Eerst: bepaal wat je hebt
Je hebt geen toegang tot code nodig. Je hebt tien minuten in je WordPress-admin nodig en één goede vraag aan degene die de site nu beheert.
Kijk in de admin-zijbalk naar:
Een "Custom Fields"- of "ACF"-menu → ACF-gedreven
Een "Elementor"-menu met "Templates" of "My Templates" → Elementor
Een "Divi"-menu met "Theme Options" → Divi
"WPBakery" of "Visual Composer" → WPBakery
Niets van dit alles, alleen standaard Posts/Pages/Appearance → Vanilla / Gutenberg
Stel daarna je ontwikkelaar één vraag: "Wat is de page builder, en wordt de meeste content beheerd via ACF-velden of direct in de editor?" Het antwoord bepaalt je scenario. Deze stap overslaan is hoe migratiescopes stilletjes verdubbelen.
De vier startarchetypen
Echte WordPress-sites vallen in vier brede vormen. De meeste zijn mengsels — maar het dominante element bepaalt het kostenverhaal.
Vanilla / Gutenberg
Het makkelijkste geval. Content zit in standaard WordPress-velden, geen propriëtaire layout-markup ingebakken. De migratie is voornamelijk content-remapping plus redirects. Laagste range, meest voorspelbare planning.
ACF-gedreven
Het vriendelijkste niet-vanilla geval. Je content zit in gestructureerde velden (tekst, afbeelding, repeater, galerij) en de templates renderen die. Een ontwikkelaar kan ACF-velden met hoge nauwkeurigheid mappen naar de content modeling van Statamic, vaak via een eenmalig script. Mid range, voorspelbaar.
Visuele builders — Elementor, Divi, WPBakery
Het moeilijkste geval, en het meest voorkomend bij serieuze zakelijke sites. Content en layout zijn versmolten: een paragraaf is niet alleen tekst, het is tekst binnen een builder-specifieke module met styling ingebakken. "Alleen de content" eruit halen werkt zelden netjes. Grootste range, breedste onbekende. We werken dit hieronder uit omdat hier de meeste verrassingen zitten.
Gemengd
De realistische meerderheid. ACF voor de content types, Elementor voor landingspagina's, Gutenberg voor de blog. De kosten landen waar je grootste "harde" component landt — meestal het visuele-builder-deel. Reken contingency in.
Waarom visuele builders het grootste risico zijn
Wanneer een site Elementor, Divi of WPBakery gebruikt, bestaat de paginacontent niet onafhankelijk van de layout. Een "hero met drie kolommen en een icon list" is geen drie tekstparagrafen — het is een geserialiseerde blob in de WordPress-database die zegt "gebruik de module van deze builder, met deze instellingen, op deze positie". Haal de builder weg en je houdt ruwe markup over die geen ander systeem zinvol kan lezen.
Daarom werkt "exporteer gewoon de content" niet voor deze sites. Je hebt drie eerlijke opties:
Vanaf nul opbouwen. Een designer-developer paar bouwt elke pagina opnieuw in Statamic. Voorspelbare kosten, langere planning, hoogste kwaliteit — je krijgt onderweg ook de kans om opgehoopte layout-drift recht te zetten.
Gedeeltelijke extractie plus opschoning. Een script trekt zichtbare tekst en afbeeldingsreferenties uit de builder-markup; een persoon zet elke pagina opnieuw in elkaar. Goedkoper, maar visuele getrouwheid daalt merkbaar.
Parallelle aanpak. Bouw de nieuwe Statamic-site naast de levende WordPress-site. Migreer pagina voor pagina in volgorde van prioriteit. Schakel verkeer over wanneer klaar. Laagste eenmalig risico, nuttig wanneer downtime-tolerantie laag is.
De juiste keuze hangt af van hoeveel van je bestaande visuele design je wilt behouden, hoeveel pagina's moeten verhuizen, en hoeveel kalendertijd je hebt. De meeste projecten die wij zien, combineren uiteindelijk twee van deze — bijvoorbeeld parallelle build voor de marketingpagina's, gedeeltelijke extractie voor blog-archiefcontent.
Wat elke migratie sowieso moet regelen
Ongeacht het archetype dekt elke WordPress-naar-Statamic migratie dezelfde vijf universele zaken:
Redirects — zonder een 301-map van oude URL's naar nieuwe dalen zoekrankings binnen weken. Niet onderhandelbaar.
Media — elke afbeelding en PDF moet mee verhuizen en bereikbaar blijven vanaf zijn oude URL.
Zoekstand — Yoast- of Rank Math-metadata wordt overgemapped naar de SEO-equivalenten van Statamic.
Formulieren en integraties — contactformulieren, CRM, nieuwsbrief-bedrading. Soms bestaat er een gelijkwaardig Statamic-equivalent; soms moet je opnieuw bedraden.
Hertraining van editors — je team leert een nieuwe admin. Reken op één tot twee uur begeleide overdracht.
Dit zijn geen onderscheidende factoren tussen archetypen — het zijn constanten. Maar ze moeten in elk contract staan.
Geautomatiseerde migratietools — wat ze wel en niet kunnen
Er bestaat een WordPress importer-addon voor Statamic. Hij kan pagina's, posts, taxonomieën en eenvoudige content overhalen. Op een vanilla WordPress-site doet hij betekenisvol werk.
Voor al het andere — ACF custom fields, Elementor builder-content, Divi shortcodes, WPBakery markup — haalt de importer de gerenderde HTML binnen, niet de gestructureerde content. Je eindigt met een Statamic-site vol bevroren HTML-blokken, zonder bewerkbare structuur eronder. Toekomstige content-bewerkingen worden pijnlijk.
De regel: elk bureau dat "we automatiseren het hele ding" pitcht zonder eerst een proof of concept op jouw specifieke site te draaien, verkoopt je een hoop, geen plan. De kosten van het terugdraaien van een slechte automatische import overstijgen meestal de kosten van een goed gescopete handmatige migratie.
Realistische budgetbanden per archetype
Geen enkel getal — elke site is anders — maar dit zijn de ranges die je kunt verwachten voor een typische kleine marketing-site (10–30 pagina's, een blog, contactformulieren; geen e-commerce):
| Archetype | Realistische tijd | Budgetband | Belangrijkste driver |
|---|---|---|---|
| Vanilla / Gutenberg | 1–2 weken | Klein | Aantal content-items |
| ACF-gedreven | 2–4 weken | Medium | Veldcomplexiteit |
| Eén visuele builder | 4–8 weken | Groter | Aantal pagina's + vereiste designgetrouwheid |
| Gemengd | 4–10 weken | Grootste, met contingency | Welk pad het grootst is in jouw mix |
Voor de kosten van het draaien van de nieuwe Statamic-site over drie jaar (los van de migratie), zie ons 3-jarig kosten- en prestatiemodel — de migratie zit vooraan in die getallen.
Vragen om te stellen voordat je een scope tekent
Gebruik deze in het kick-offgesprek. De antwoorden scheiden zorgvuldige bureaus van optimistische:
"Hebben jullie naar onze daadwerkelijke contentstructuur gekeken, niet alleen naar het aantal pagina's?"
"Wat is jullie specifieke plan voor de [jouw builder]-pagina's?"
"Wat verliezen we als we content niet vanaf nul opnieuw doen?"
"Hoe worden redirects afgehandeld, en met welke dekking?"
"Welke integraties breken, en wat vervangt ze?"
"Hoe gaan jullie om met onze vertalingen of andere talen?"
Als je geen specifieke, scope-gedefinieerde antwoorden krijgt op deze vragen, gaat de prijs die je tekende bewegen.
Wanneer NIET migreren
Sommige sites zijn de verhuizing niet waard. Eerlijke signalen:
Het verkeer van de site sterft sowieso af — een migratie lost geen marketingprobleem op.
De site wordt eens in de twee of drie jaar bewerkt — er is geen onderhoudspijn om te verlichten.
Je zit vast aan een WordPress-only plugin (LearnDash, BuddyBoss, een complexe WooCommerce-setup) zonder Statamic-equivalent op je roadmap.
Soms is het juiste antwoord "blijf, lap op, bespaar het budget".
Over dit artikel
Ik ben Andrii Trush. Ik werk aan Statamic-projecten in heel Europa — ik heb WordPress-sites van elke vorm op deze lijst gemigreerd, en ik heb prospects ook verteld wanneer ze het niet moeten doen. De cijfers en vormen hierboven komen uit die projecten, niet uit een vendor deck. Wil je een sanity check op je eigen situatie? Neem contact op.
Kunnen we de bestaande WordPress-site live houden terwijl we de Statamic-versie bouwen?
Ja — dat is de parallelle aanpak die in het artikel wordt genoemd. Je laat WordPress draaien op zijn huidige domein en bouwt Statamic op een staging-URL tot het klaar is. De omschakeling gebeurt op DNS-niveau zodra de redirect-map klaar is. Het kost iets meer kalendertijd, maar elimineert downtime — dat telt het meest voor sites met stabiel verkeer of betaalde campagnes.
Hoe beschermen we onze zoekrankings tijdens de migratie?
Drie dingen tellen: een complete 301 redirect-map van oude URL's naar nieuwe (inclusief paginering, taxonomie-archieven en feed-URL's), behoud van meta titles en descriptions, en de nieuwe sitemap indienen bij Google Search Console zodra de nieuwe site live is. De meeste rankingdalingen die we zien tijdens migraties komen door gemiste redirects op long-tail URL's — blogposts van jaren geleden die nog steeds zoekverkeer krijgen. Een serieuze migratiescope bevat een redirect-QA-pass, niet alleen de voor de hand liggende hoofdpagina's.
Wat gebeurt er na de migratie met onze bestaande WordPress-plugins?
Voor elke plugin moet je expliciet een vervangingsbesluit nemen. Sommige hebben directe Statamic-equivalenten (formulieren, SEO, analytics — gedekt door Statamic-addons of ingebouwde features). Sommige moeten via andere tools opnieuw bedraad worden (nieuwsbrief-integraties verschuiven vaak naar afhandeling op het niveau van de form-submit). Een handvol heeft helemaal geen equivalent en vereist een custom build of een herziening. Map je actieve plugins voordat je een offerte tekent — verrassingen hier zijn de op één na grootste budgetkiller na page builders.
Moeten we tijdens de migratie herontwerpen, of eerst migreren en later herontwerpen?
Doe ze meestal samen wanneer het bestaande design echt versleten is of wanneer je sowieso betaalt voor extractie van visuele-builder-content — je raakt dan toch al elke pagina aan. Migreer eerst wanneer het huidige design prima is en het doel alleen het ontsnappen aan de operationele pijn van WordPress is. Beide tegelijk doen kost minder in totaal dan twee opeenvolgende projecten, maar voegt risico toe: scope creep is reëel. Als je ze bundelt, lock dan het nieuwe design vóórdat de migratiecode begint, niet parallel.