Waarom een migratie zelden 'gewoon kopiëren' is
De meeste site-eigenaren denken dat een WordPress-migratie een paar uur werk is — bestanden kopiëren, database exporteren, importeren op de nieuwe host, klaar. In de praktijk is dat het moment waarop dingen mis gaan: 404-fouten op oude URL's die nog in Google staan, gebroken interne links, verloren afbeeldingen door verschillende uploadpaden, een Search Console die plotseling honderden crawl-errors meldt, en in het ergste geval een ranking-daling van twee tot zes weken voordat alles weer in balans is.
Bij Fast 4 You hebben we de afgelopen jaren tientallen WordPress-migraties uitgevoerd — van shared hosting naar managed WordPress (Kinsta, WP Engine, ons eigen platform), van een verouderde Joomla- of Drupal-site naar WordPress, van WordPress.com naar self-hosted, en migraties bij hosting-providers die de stekker eruit trokken. Wat we steeds zien: het technische kopieerwerk is misschien 20% van het project. De andere 80% is voorbereiding (URL-mapping, plugin-audit, mediabestanden-inventarisatie), uitvoering met staging-test, en post-launch monitoring waarin we de eerste twee weken elke dag controleren of er geen SEO-bloeding optreedt.
De migratietrajecten waar we wel eens van afzien zijn de paar gevallen waarbij de bron-site niet meer toegankelijk is (hosting-provider die de plug heeft getrokken zonder export-toegang) en er geen recente back-up is. In die situaties wordt het reconstructiewerk via web.archive.org of bij de oude hoster vragen om noodtoegang — dat kan, maar valt buiten standaardtraject en rekenen we apart.
De meest voorkomende migratie-aanleidingen die we zien: een hoster die te traag is geworden of waar de support niet meer reageert, een siteoperator die zelf het beheer wil overdragen aan een specialist, een merger of rebranding waarbij twee sites op één domein moeten landen, en de klassieke 'mijn neefje heeft de site jaren geleden gebouwd en nu woont hij in Australië'-situatie. Voor elk van die scenario's hebben we een vast stappenplan.
