Van WordPress naar Drupal

Overstappen van WordPress naar Drupal is voor de meeste sites geen verbetering.
Draait je site, is hij bijgewerkt en doet hij wat je nodig hebt, dan kost een migratie geld zonder resultaat.
De overstap verdient zichzelf terug wanneer je contentstructuur, je talen, je rechten of je integraties tegen de grenzen van WordPress aanlopen.
Die afweging maak ik eerst, voor er een regel code geschreven wordt.

Wanneer je niet moet overstappen

Een goed draaiende blog of een overzichtelijke bedrijfssite hoort op WordPress te blijven staan.
WordPress is daar een degelijk systeem met veel kant-en-klare functionaliteit en de migratiekost betaalt zich nooit terug.
Ik zeg dat liever voor de opdracht dan erna.

• ✓ Je hebt een blog of nieuwssite met artikels, categorieën en een auteur per stuk.
• ✓ Je bedrijfssite heeft twintig tot vijftig pagina's, één taal en twee mensen die eraan werken.
• ✓ Je site is snel, bijgewerkt en er is iemand die de updates uitvoert.
• ✓ Je wil hoofdzakelijk een nieuw ontwerp, want dat kan binnen WordPress.
• ✓ Je hebt geen technisch profiel intern en geen budget voor onderhoud, want Drupal vraagt meer van die twee.

De keuze gaat niet over welk platform beter is, maar over wat je site moet kunnen.
Die vergelijking werkte ik uit in Drupal versus WordPress.
Blijkt daaruit dat WordPress volstaat, dan stopt het gesprek daar.

De echte aanleidingen om wel over te stappen

Een overstap is te verdedigen zodra WordPress werk verplaatst in plaats van oplost.
Vijf aanleidingen komen terug en meestal spelen er twee of drie tegelijk.

Contentstructuren met relaties

WordPress kent posts en pages, alles daarbuiten komt van plugins.
Zodra je met custom post types, ACF-veldgroepen en drie relatieplugins producten aan projecten aan vestigingen knoopt, bouw je een contentmodel bovenop een systeem dat er niet voor bedoeld is.
Drupal heeft entiteiten, velden, taxonomie en entity reference in de kern, dus relaties zijn geen bouwwerk maar configuratie.
Dat verschil merk je pas bij de derde uitbreiding.

Meertaligheid

Meertaligheid zit in Drupal core, in WordPress is het een plugin.
Nederlands, Frans en Engels naast elkaar houden betekent dat velden, menu's, taxonomietermen, instellingen en interfaceteksten elk een vertaling nodig hebben, met een eigen workflow en revisiegeschiedenis.
Drupal regelt dat per veld en per entiteit.
Bij meer dan twee talen of een redactie die per taal anders werkt, is dit vaak het argument dat de rest overbodig maakt.

Rechten en workflows

Niet elke redacteur mag alles en dat is in Drupal fijnmazig in te stellen.
Rechten gelden per entiteitstype, per bundel, per veld en per workflowtoestand.
Met Content Moderation en Workspaces laat je concept, ter nakijk en gepubliceerd naast elkaar bestaan, wijzigingen goedkeuren door iemand anders en een volledige set aanpassingen in één keer live gaan.
Voor een organisatie met een communicatiedienst en lokale beheerders is dat het verschil tussen afspraken en afdwingbare regels.

Integraties voorbij wat een plugin kan

Koppelingen met een ERP, een CRM, een PIM of een ledenadministratie zijn maatwerk, geen plugin.
Drupal geeft je een servicecontainer, een queue- en cronmechanisme, een eigen importlaag en JSON:API in core, dus je bouwt een koppeling als code die in Git staat, in code review gaat en getest kan worden.
Een pluginlandschap waarin drie partijen elk een stuk van je datastroom beheren is minder houdbaar dan eigen code.

Schaal

Schaal gaat over redactie en datavolume, niet alleen over bezoekersaantallen.
Tienduizenden nodes, tientallen redacteuren, honderden overzichten met filters en facetten en een cachestrategie die per component klopt: daar blijft Drupal met Views, cache tags en BigPipe voorspelbaar.
Bij vijfhonderd pagina's en duizend bezoekers per dag is schaal geen argument.

Wat niet meekomt: je plugins

Plugins migreren niet, want ze bestaan alleen binnen WordPress.
Wat een plugin voor je deed, bouw je in Drupal opnieuw met core of met een contribmodule en dat is meestal het kleinste deel van het werk.
De meest voorkomende vertalingen:

• Yoast of Rank Math wordt de Metatag-module, met je bestaande titels en metabeschrijvingen mee naar de metatagvelden.
• WPML of Polylang wordt de meertaligheid uit Drupal core.
• ACF wordt velden op entiteiten, zonder extra module.
• Contact Form 7 of Gravity Forms wordt Webform.
• Een paginabouwer wordt Paragraphs of Layout Builder en dat is een ontwerpbeslissing, geen module-installatie.
• Een cacheplugin wordt de caching uit core, met cache tags en BigPipe.

Het echte werk zit in de plugins zonder equivalent.
Die worden maatwerk, of ze vallen weg omdat niemand ze nog gebruikt.
Welke van de twee het is, bepaalt de inventarisatie en daar zit dan ook een van de grootste kostenposten.

Mijn aanpak: inventariseren, modelleren, migreren, controleren

Een migratie is een dataproject met een deadline, geen herbouw met een kopieeractie erbij.
Vier stappen en de eerste bepaalt of de andere drie nodig zijn.

1. Inventarisatie. Alle post types, taxonomieën, ACF-veldgroepen, plugins en templates in kaart, plus de volledige URL-lijst uit de sitemap, Search Console en de serverlogs.
   Resultaat: wat mee moet, wat vervalt en waar het maatwerk zit, geordend op impact.
2. Contentmodel in Drupal. Het model opnieuw ontworpen in entiteiten, bundels en velden, in plaats van de WordPress-structuur één op één na te bouwen.
   Hier wordt de winst van de overstap gemaakt, want deze stap overslaan betekent dat je je oude beperkingen meeneemt naar een duurder platform.
3. Migratie als code. De Migrate API zit in Drupal core, met Migrate Plus en Migrate Tools erbovenop staan de migraties als configuratie in Git.
   Daardoor zijn ze herhaalbaar, terug te draaien en te testen.
   Voor blogcontent bestaat de contribmodule wordpress_migrate, die een WXR-export inleest, maar die heeft nog geen stabiele release.
   Meestal schrijf ik eigen sourceplugins rechtstreeks op de WordPress-database, want een WXR-export verliest ACF-velden en relaties.
4. Controleren en herhalen. De migratie draait tientallen keren voor ze definitief is.
   Aantallen per contenttype vergelijken, steekproeven op velden en interne links en op de dag van de overstap een verse import vanaf de laatste WordPress-stand.

Het bredere migratietraject, inclusief upgrades van bestaande Drupal-sites, staat op Drupal migratie en upgrade.
De aanpak is dezelfde, alleen de bron verschilt.

URL-structuur en redirects: wat je posities beschermt

Je URL-structuur zo veel mogelijk behouden is de veiligste keuze.
Pathauto genereert paden per contenttype, dus je legt de bestaande permalinkstructuur na.
Volledig identiek is het zelden: trailing slashes, feeds en query-URL's zoals /?p=123 vangen we met 301-redirects op.
Pathauto is een stabiele contribmodule en ondersteunt Drupal 11.

Waar een URL toch wijzigt, hoort een 301 die rechtstreeks naar de nieuwe pagina wijst.
De Redirect-module beheert die redirects en de meegeleverde Redirect 404-submodule logt welke oude adressen nog aangevraagd worden zodat je vergeten gevallen na livegang alsnog ziet.
Redirectketens laat ik niet staan: elke oude URL wijst in één stap naar zijn eindpunt.

Bij de oplevering horen een nieuwe sitemap, canonicals die kloppen, een nagekeken robots.txt en de titels en metabeschrijvingen uit Yoast of Rank Math mee naar de metatagvelden.
Verlies van zichtbaarheid komt bijna altijd uit een van die vier, niet uit het CMS.
Meer daarover bij technische SEO.

Je domeinnaam zelf verhuist niet mee met het CMS, die blijft staan en wijst op de dag van livegang naar de nieuwe hosting.
Welke stappen je voor, tijdens en na de omschakeling zet om je posities te houden, zette ik op een rij in website migreren zonder je vindbaarheid te verliezen.

Media en bijlagen

Media is bij een WordPress-migratie meestal het rommeligste onderdeel.
In WordPress zijn afbeeldingen attachments met hun eigen posts, vaak gedupliceerd, soms hardgecodeerd in de content.
In Drupal worden dat media-entiteiten met velden, dus alt-teksten, rechten en hergebruik worden pas dan beheerbaar.

Concreet: bestanden overzetten met behoud van het pad waar dat kan, attachments omzetten naar media-entiteiten, inline afbeeldingsverwijzingen herschrijven naar embeds en afbeeldingsstijlen opnieuw definiëren zodat je moderne formaten en de juiste afmetingen uitlevert.
Ontbrekende alt-teksten komen hier boven water en die vul je beter aan tijdens de migratie dan erna.

Op welke Drupal-versie je landt

Je komt uit op Drupal 11, momenteel 11.4.x.
Nieuw bouwen op Drupal 10 heeft geen zin meer, want Drupal 10 loopt op 9 december 2026 uit support.
Wachten op een volgende versie hoeft niet, want het pad van 11 naar 12 is een gewone upgrade binnen dezelfde architectuur.
Hoe zo'n versie-upgrade van een bestaande Drupal-site verloopt, staat op Drupal migratie en upgrade.

Wat de overstap kost

Een prijs zonder inventarisatie is een gok en die geef ik niet.
Wat de kost bepaalt: het aantal contenttypes en velden, het aantal talen, de plugins waarvoor maatwerk nodig is, de mate waarin het ontwerp hergebruikt wordt en vooral de staat van je data.
Duizend blogartikels met een vast veldpatroon zijn eenvoudiger dan tweehonderd pagina's die elk anders opgebouwd zijn.

Mijn tarieven zijn 75 tot 95 euro per uur of 650 tot 800 euro per dag, exclusief btw, lager bij lange trajecten en terugkerende klanten.
Ter vergelijking: Belgische Drupal-freelancers afficheren op Malt tussen 400 en 600 euro per dag met een mediaan rond 550 euro, de bredere Belgische IT-freelancemarkt zit rond 710 euro per dag en Freelance.nl noemt 70 tot 90 euro per uur voor Nederland.
De volledige toelichting staat op tarieven en de opbouw van zo'n dagtarief in wat een freelance Drupal developer kost.

De inventarisatie zelf is een afgebakende opdracht van enkele dagen en levert een lijst met wat migreert, wat maatwerk wordt en waar het risico zit.
Daarna weet je wat het kost en ook of het de moeite is.
Beide uitkomsten zijn een geldig resultaat.

Waarom met mij

Ik werk meer dan tien jaar met Drupal, als freelance architect vanuit Herk-de-Stad voor klanten in België en Nederland.
Ik stap in je bestaande Git-flow, volg de conventies die er al zijn en neem deel aan code review.
Een rommelige WordPress-database snel doorgronden hoort bij het werk.
Wat ik eerder opleverde staat bij de projecten, de updates en opvolging na livegang bij Drupal onderhoud en support en het bredere technisch beheer bij technisch beheer.