Custom CMS exporteren naar WordPress: data uit een maatwerk-systeem halen

Heb je een website die ooit op maat is gebouwd, maar inmiddels niemand meer wil onderhouden? Misschien is de oorspronkelijke ontwikkelaar weg, is de codebase ondoorgrondelijk, of zijn de hostingkosten hoger dan ze zouden moeten zijn. Of werkt de admin nog wel, maar lukt het niemand meer om nieuwe functionaliteit toe te voegen. In zo’n situatie kan custom cms exporteren naar wordpress een praktische en toekomstbestendige oplossing zijn.

In zo’n situatie staat overstappen naar een gangbaar systeem als WordPress vaak op tafel. De vraag is dan vooral: hoe krijg je je data eruit? Bij een Joomla- of Drupal-site werken bestaande tools. Bij een eigen CMS sta je vrijwel altijd voor maatwerk.

Hieronder de aanpak die ik bij dit soort projecten volg. Ervaring uit veel jaren PHP, een paar Laravel-applicaties die ik heb omgezet, en eigen import-scripts die ik per project bouw. Geen kant-en-klare plugin, wel een herhaalbare werkwijze.

Wanneer custom CMS exporteren naar WordPress logisch is

Niet voor elk maatwerk-systeem is overstappen verstandig. Verbeteren boven herbouwen geldt nadrukkelijk bij custom CMS-systemen. Soms is een opgepoetste eigen back-end waardevoller dan een halfgemaakte WordPress-versie.

Wel is overstappen het overwegen waard als:

• De oorspronkelijke ontwikkelaar is niet meer beschikbaar of betaalbaar
• De codebase gebruikt verouderde PHP-versies (5.x of 7.0) zonder upgrade-pad
• Beveiligingsupdates blijven uit en de site loopt risico
• Het contentteam vindt de admin te ingewikkeld en publiceert daardoor minder
• De hosting is duurder dan een moderne setup met WordPress nodig heeft
• Toekomstige functionaliteit (lidmaatschap, betaling, integraties) is in WordPress eenvoudiger te realiseren

Niet doen als:

• De huidige site doet precies wat hij moet doen en werkt stabiel
• Het systeem is gebouwd voor een use-case die WordPress niet kan dekken (echte enterprise workflow, complexe rechtenstructuren, native mobile)
• Je geen access hebt tot de bron-database (zonder export is migratie vrijwel onmogelijk)

In dat laatste geval moet de huidige eigenaar of leverancier eerst meewerken aan een database-dump. Zonder access tot de data is migreren een paar weken reverse-engineeren via screen-scraping, en dat is bijna altijd duurder dan een nieuwe site bouwen.

Stap 1: krijg toegang tot de database

Dit is de stap waar de meeste projecten op vastlopen. Een custom CMS is meestal gebouwd op een gewone SQL-database (MySQL, MariaDB, PostgreSQL). Maar de toegang tot die database vereist:

• Inloggegevens voor de hosting of server
• Een tool om bij de database te komen (phpMyAdmin, een SSH-tunnel, of directe MySQL-toegang)
• Goedkeuring van de huidige eigenaar (juridisch en praktisch)

Heb je geen toegang? Vraag dan om een SQL-dump (.sql bestand) van de hele database. Dat is een standaard verzoek en een fatsoenlijke hostingpartij of ontwikkelaar levert dat binnen een dag.

Heb je wel toegang? Maak dan eerst een volledige backup voordat je iets aanraakt. Een SQL-dump downloaden via phpMyAdmin of via de command line:

bash

mysqldump -u gebruiker -p database_naam > backup.sql

Bewaar dit bestand veilig en versleuteld. In de meeste gevallen bevat een CMS-database persoonsgegevens, en die vallen onder AVG.

Stap 2: breng de database-structuur in kaart

Open de database in een tool zoals phpMyAdmin of TablePlus en bekijk de tabellen. Bij een standaard custom CMS zie je iets als:

• articles of posts voor de hoofdcontent
• categories of taxonomy voor de classificaties
• users voor accounts
• media of attachments voor bestanden
• settings voor configuratie
• En vaak een aantal koppeltabellen (article_tags, article_categories)

Maak een schema in een spreadsheet:

Dit is de mapping. Hoe completer en eerlijker hij is, hoe soepeler de import.

Custom velden (custom_subtitle, external_link, event_date) gaan vaak naar ACF Pro of naar postmeta. Dat krijgt elk een eigen rij in het mapping-schema.

Stap 3: bouw een import-script

Een custom CMS heeft geen kant-en-klare WordPress-importer. Die schrijf je zelf.

In de praktijk gebruik ik een van deze drie aanpakken:

Aanpak A: WP-CLI met een eigen PHP-script. Het krachtigst en het meest gebruikt. Je schrijft een PHP-script dat de bron-database leest en via wp_insert_post(), wp_insert_term() en update_post_meta() records aanmaakt in WordPress. Draaibaar via WP-CLI op de server.

Aanpak B: WP All Import met een tussenstap via CSV. Exporteer per bron-tabel een CSV (articles.csv, categories.csv, users.csv). Importeer in WordPress via de WP All Import-plugin. Goed voor sites tot 5.000 records, omslachtig daarboven.

Aanpak C: REST API-koppeling. Het bron-CMS en WordPress praten met elkaar via REST. Werkt als beide systemen API’s hebben en je een paar weken iteratief kunt testen.

Voor de meeste projecten gebruik ik aanpak A. Hier een voorbeeld-snippet (illustratief, simplified):

php

$old_db = new wpdb('user', 'pass', 'olddb', 'localhost');
$articles = $old_db->get_results("SELECT * FROM articles");

foreach ($articles as $article) {
    $new_id = wp_insert_post([
        'post_title'   => $article->title,
        'post_content' => $article->body,
        'post_date'    => $article->publish_date,
        'post_status'  => 'publish',
        'post_type'    => 'post',
    ]);

    update_post_meta($new_id, '_legacy_id', $article->id);
    update_post_meta($new_id, 'external_link', $article->external_link);
}

De _legacy_id is belangrijk. Daarmee kun je later 301-redirects en URL-mappings opbouwen op basis van de oude ID’s.

Stap 4: media meeverhuizen

Custom CMS-systemen slaan media vaak op in een eigen map, zoals /uploads/ of /media/. WordPress gebruikt /wp-content/uploads/.

Drie opties:

1. Kopieer de bestanden 1-op-1 en pas de paden in de gemigreerde content aan via een zoek-en-vervang in de database
2. Laat het script de bestanden downloaden en herregistreren via wp_insert_attachment() en wp_generate_attachment_metadata(). Dit geeft WordPress controle over de media-bibliotheek
3. Gebruik een externe storage (S3 of een eigen CDN) en houd de bestanden waar ze waren

Voor lange-termijn-beheer kies ik bijna altijd optie 2. WordPress wil zijn eigen media-bibliotheek correct opbouwen voor zaken als image sizes, alt-teksten en mediagebruik in posts. Optie 1 werkt snel maar geeft later problemen.

Stap 5: URL-structuur en 301-redirects

Een custom CMS heeft vaak eigen URL-patronen. Bijvoorbeeld /article.php?id=42 of /news/42/oude-titel-hier. In WordPress heb je standaard /2024/06/oude-titel-hier/ of een eigen permalink-structuur.

Verlies geen ranking door deze stappen te nemen:

1. Crawl de oude site met Screaming Frog en exporteer alle URLs
2. Map elke oude URL aan een nieuwe. Gebruik de _legacy_id postmeta die je in stap 3 hebt opgeslagen
3. Genereer een redirect-CSV met patronen zoals /article.php?id=42 → /oude-titel-hier
4. Importeer de redirects in de Redirection-plugin of voeg ze toe aan .htaccess
5. Test elke belangrijke redirect voor lancering
6. Dien de nieuwe sitemap in bij Google Search Console direct na lancering

Vergeet hier niet de aandacht voor canonical URLs en de “Change of Address”-tool in Search Console.

Wat kost een custom CMS migratie

Bandbreedte voor de meeste projecten:

• Klein systeem (50 tot 500 records, één hoofdtabel): €2.500 tot €4.500
• Middelgroot systeem (1.000 tot 5.000 records, meerdere content types): €4.500 tot €8.000
• Groot systeem (10.000+ records, complexe relaties, custom workflows): €8.000 tot €15.000

Voor het werk reken ik €95 per uur, exclusief btw. Dat is mijn tarief voor migratie, server en database. Daarbinnen zit altijd:

• Volledige database-inventarisatie en mapping
• Custom import-script in PHP of via WP-CLI
• Media-migratie met herregistratie in WordPress
• 301-redirects met behoud van legacy ID’s
• Twee weken nazorg na lancering

Een custom CMS migratie is bijna nooit “een paar uur werk”. Reken op een traject van vier tot twaalf weken doorlooptijd, afhankelijk van complexiteit.

Wat ik bij dit soort projecten doe

Mijn werkwijze:

1. Gratis intake van 20 minuten om de scope te peilen
2. Database-toegang testen en een eerste inventarisatie maken
3. Schriftelijke offerte met urenraming, scope-beschrijving en bovengrens
4. Eerste import-iteratie met een steekproef van 10 records
5. Volledige import met validatie
6. Staging-site met de gemigreerde content
7. Lancering op een rustig moment in de week
8. Twee weken actieve monitoring via Google Search Console en de Redirection-plugin

Bij mij heb je direct contact met degene die het werk uitvoert. Geen tussenlaag, geen accountmanager. Geen bureau-tarieven en geen lange trajecten met onduidelijke meerkosten.

Heb je een maatwerk-systeem waar je vanaf wilt? Stuur me een korte omschrijving, het aantal records en of je database-toegang hebt. Dan kijk ik kosteloos of een migratie haalbaar is. Meer artikelen over dit soort projecten staan in de categorie website migratie. Voor de scope van mijn werk zie je terug op diensten.