Website migratie checklist: 12 fasen + 5 roadmaps 2026

Een MKB-eigenaar uit Middelburg belde vorig jaar in paniek. Zes weken na een migratie door een goedkope agency was zijn organisch verkeer met 47 procent gekelderd. 380 productpagina’s waren uit de top-100 van Google verdwenen. De oorzaak was banaal. Geen enkele redirect was gebouwd van de oude PrestaShop-URL-structuur naar de nieuwe WooCommerce-permalinks. Zijn oude URLs stonden allemaal op 404. Deze website migratie checklist voorkomt precies dat.

Het is de werkwijze die ik in mijn eigen praktijk hanteer: twaalf fasen en vijf numbered roadmaps, uitgewerkt per platform en per hostingpaneel. Reken op 2 tot 6 weken doorlooptijd end-to-end, afhankelijk van site-omvang. Voor een simpele MKB-brochure ben je 25 tot 40 uur bezig. Voor een grote WooCommerce-shop met live orders loopt dat op naar 60 tot 140 uur.

Komt je site uit Webflow, gebruik dan naast deze algemene checklist het stappenplan voor Webflow naar WordPress voor de platformspecifieke overdracht. Verhuis je vanaf WordPress.com naar een eigen WordPress-installatie, volg dan ook de specifieke route voor WordPress.com naar WordPress.org overstappen. Gaat de verandering vooral om je page builder, bekijk dan de route voor Elementor naar Bricks of Gutenberg migreren met behoud van inhoud.

Wanneer heb je deze migratie-workflow nodig?

Niet elke wijziging heet meteen migratie. Wijzigt je URL-structuur, hosting, platform of domein, dan zit je in migratie-territorium. In mijn praktijk zie ik vijf scenario’s regelmatig terugkomen. Elk scenario vraagt een iets andere aanpak binnen dezelfde 12 fasen.

1. Platform-switch: bijvoorbeeld van Shopify of PrestaShop naar WooCommerce. Grootste risico: URL-schema wijzigt volledig, dus alle redirects moeten handmatig gemapt worden. Voor die specifieke Shopify-naar-Woo case link ik naar mijn deep-dive PrestaShop naar WooCommerce migratie.
2. Hosting-move: dezelfde site, andere server. URL-schema blijft, maar DNS, SSL en mail moeten netjes overgezet. Zie hosting-migratie zonder downtime.
3. Domein-rebrand: nieuwe domeinnaam, meestal na naamswijziging of overname. Grootste risico is link-equity verlies en verlies van brand-search-verkeer. Voor de complete workflow zie domeinnaam veranderen zonder ranking-verliezen.
4. HTTP naar HTTPS: laatste 2 procent van de sites die dit in 2026 nog niet hebben gedaan. Zie HTTP naar HTTPS migratie 2026.
5. Theme-refactor: nieuwe theme op bestaande site. URL blijft, maar structured data, canonicals en internal link-graph veranderen vaak. Zie WordPress theme wisselen zonder SEO-verlies.

Zo schat ik de zwaarte van een migratie in:

Website migratie checklist: de 12 fasen die je moet volgen

Deze twaalf fasen vormen de ruggengraat van elke migratie in mijn portfolio. Platform en grootte veranderen daar niets aan. Wat verschilt is de tijdsinschatting per fase, niet welke fasen je overslaat. Overslaan van fase 3 (backup + rollback plan) of fase 8 (redirect-map) is exact hoe de Middelburg-case ontspoorde.

Totaal 49 tot 141 uur werk. Tegen mijn tarief van €95/uur is dat €4.655 tot €13.395, exclusief hosting, plugin-licenties en eventuele agency-koppelingen. De onderkant van die range is een simpele MKB-brochure, de bovenkant een WooCommerce-shop met veel orderhistorie en membership-integraties.

Fase 1–3: pre-migratie audit (roadmap 1)

De eerste drie fasen zijn de belangrijkste in het hele project. Een goede audit voorkomt dat je in fase 8 tegen verrassingen aanloopt, en een goed rollback-plan is de enige verzekering die je hebt als fase 10 ontspoort. Ik werk deze fase af in exact deze volgorde:

1. Volledige URL-crawl via Screaming Frog SEO Spider. De gratis versie crawlt tot 500 URLs, wat volstaat voor de meeste MKB-brochure-sites. Boven de 500 URLs kost een licentie £199 per jaar en kun je unlimited crawlen plus scheduling en integraties met GSC.
2. Content-inventaris export naar CSV. Kolommen: URL, titel, wordcount, laatst-gewijzigd, verkeer (uit GA4), backlinks (uit Ahrefs of GSC). Deze CSV wordt in fase 4 je master-URL-mapping-document.
3. GA4-export laatste 12 maanden: top-100 landingspagina’s op sessies. Deze pagina’s krijgen prioriteit in de redirect-map. Verkeer volgt kern-URLs, niet elke oude blog uit 2018.
4. Google Search Console top-queries en top-pages export. Dit toont wat Google denkt dat je site is over. Als een pagina 300 impressies per dag krijgt op query “keuken vervangen Antwerpen” wil je die pagina absoluut niet verliezen in de migratie.
5. Backlink-inventaris via Ahrefs Site Explorer (Lite-plan vanaf $129/maand, of gratis Webmaster Tools voor eigen sites), Semrush Backlink Analytics of Moz Link Explorer. Prioriteer de top-100 pages op referring domains.
6. Plugin en theme audit: exporteer je huidige stack (bij WordPress: wp plugin list --format=csv > plugins.csv) en bepaal per plugin of hij mee moet naar de nieuwe stack.
7. Custom-code audit: alles wat is aangepast in functions.php, custom templates, mu-plugins, custom PHP endpoints. Documenteer of dit ook naar de nieuwe site moet of geobsoleteerd is.
8. Media library-scan: welke files zijn nog in gebruik, welke niet. Grote files (>2 MB) markeren voor eventuele compressie tijdens migratie.
9. Database-audit: tabel-omvang, WooCommerce orders/users/comments-totalen, custom tabellen van plugins. Dit bepaalt hoe zwaar fase 7 wordt.
10. SEO-baseline snapshot: rankings top-20 keywords, Core Web Vitals score, GSC clicks/impressies laatste 90 dagen. Deze getallen zijn je referentie in fase 12.

Voor bestaande WooCommerce-shops link ik naar PrestaShop naar WooCommerce migratie, CCV Shop naar WooCommerce migratie en Lightspeed eCom naar WooCommerce migratie. Voor blogs zie Blogger naar WordPress migreren en Ghost CMS naar WordPress migratie. Voor page-builders naar block-editor: zie Divi naar Gutenberg migratie.

De rollback-plan-component van fase 3 vraagt specifieke aandacht. Zie mijn eerdere gids over de WordPress backup 3-2-1 regel en test-restore. Praktisch: minimaal drie kopieën, twee media, één offsite, plus een geverifieerde test-restore binnen 24 uur voorafgaand aan de migratie.

Migratie-checklist per platform-source

Om te bepalen welke tool je in fase 6 en 7 kiest, gebruik ik deze matrix. Elk platform heeft een eigen native export-formaat of een specifieke migratie-plugin die het meeste werk uit handen neemt.

Tools die ik voor de meeste WordPress-naar-WordPress migraties inzet:

1. All-in-One WP Migration Unlimited van Servmask: $69 voor de Unlimited extension die de 512 MB import-limit omzeilt. Werkt voor sites tot circa 5 GB.
2. Duplicator Pro: vanaf $69/jaar, ondersteunt grote sites met multi-part archives en cloud-destinations.
3. Better Search Replace (WP.org, gratis): versie 1.4.11 (juni 2026), onmisbaar voor het bijwerken van serialized data na een URL-change.
4. Cart2Cart: automated e-commerce migration tussen 80+ platforms. Prijs vanaf $69 per migratie, gebaseerd op producten/klanten/orders. Gratis demo migratie voor 10 items.

Fase 8: redirect-map bouwen (de belangrijkste stap)

Van alle twaalf fasen is deze het meest onderschat. Ik heb sites gezien met perfect gemigreerde content en 0 redirects, en daarmee 60 procent van hun organische verkeer verspeeld in 4 weken. Google verwijst zelf naar deze stap in de officiële site-move documentatie: redirects minimaal 1 jaar aanhouden om alle signalen te transfereren.

Voor de bulk-import van redirects in WordPress zie mijn deep-dive 301 redirects bulk na migratie WordPress. Kort samengevat: bouw een CSV met kolom A = oude URL en kolom B = nieuwe URL. Importeer die via de Redirection plugin of via .htaccess. Die plugin staat op versie 5.10.0 (augustus 2026) en heeft 2 miljoen actieve installaties.

Redirect status-code beslissingstabel:

Voor 95 procent van je migratie-redirects gebruik je 301. Alleen bij method-preserving POST-endpoints (bijv. webhook-callbacks van betaalproviders) gebruik je 308. Sites die per ongeluk 302 in plaats van 301 pushen, verliezen typisch 20 tot 40 procent van hun organische verkeer in de eerste 60 dagen na cutover.

Apache/.htaccess redirects (voor cPanel/Plesk/DirectAdmin hosts).

# Simpele 301 per URL
Redirect 301 /oude-pagina /nieuwe-pagina
Redirect 301 /oude-categorie/product-a /nieuwe-categorie/product-a

# Category-wide regex-move: alle URLs onder /blog/oud/ naar /nieuws/nieuw/
RedirectMatch 301 ^/blog/oude-categorie/(.*)$ /nieuws/nieuwe-categorie/$1

# Trailing slash normalisatie (verplicht na PrestaShop-naar-Woo migratie)
RewriteEngine On
RewriteRule ^(.*[^/])$ /$1/ [R=301,L]

Nginx-equivalent (voor RunCloud/GridPane/managed VPS).

# In server-block
location = /oude-pagina { return 301 /nieuwe-pagina; }

# Regex-based bulk move
location ~ ^/blog/oude-categorie/(.*)$ {
    return 301 /nieuws/nieuwe-categorie/$1;
}

WP-CLI bulk-import via de Redirection plugin.

# Redirection CLI-package installeren (eenmalig per site)
wp package install boonebgorges/wp-cli-redirection

# CSV-import (kolommen: source, target)
wp redirection add-from-csv redirects.csv --group=1

# Sanity-check: aantal geladen redirects
wp redirection list --format=count

Post-migratie search-replace bij een domein-change.

Bij een domein-rebrand of HTTPS-migratie vervang je alle oude URLs in de nieuwe database. Gewone SQL UPDATE breekt serialized data, omdat WordPress URLs opslaat met byte-length prefixes (s:26:"http://staging.example.com"). De enige veilige weg is wp search-replace met de --precise flag. Die unserializet elke waarde, vervangt hem, en serializet opnieuw.

# Backup EERST
wp db export pre-search-replace-backup.sql

# Dry-run om te zien hoeveel vervangingen
wp search-replace 'https://oude-site.nl' 'https://nieuwe-site.nl' \
    --all-tables --precise --dry-run

# Echt uitvoeren
wp search-replace 'https://oude-site.nl' 'https://nieuwe-site.nl' \
    --all-tables --precise

Fase 9: test-fase staging (roadmap 2)

Voordat je live gaat, moet de staging-omgeving hetzelfde gedrag vertonen als de latere productie. Dit is de checklist die ik doorloop, minimum 4 uur, tot 16 uur voor complexe shops:

1. Frontend visuele check: homepage, top-10 pagina’s op verkeer, checkout-flow, contactformulier, alle CTA-knoppen. Screenshots vergelijken met oude site.
2. Backend admin check: login werkt, plugin-activering zonder errors, media library toegankelijk, gebruikersrollen intact.
3. WooCommerce specific: test-order via cash-on-delivery, mail-notificaties komen aan, PDF-factuur genereert correct, voorraad-update werkt.
4. Redirect-test: pak 50 top-URLs uit oude site, check via curl -I of httpstatus.io dat elke URL een 301 naar de correcte nieuwe URL geeft.
5. Performance-baseline: PSI-score van staging vs oude site vergelijken. Doel: minimaal gelijk, liefst beter dan pre-migratie.
6. Mobile-check: iOS Safari, Android Chrome, minimaal drie viewport-groottes (375px, 768px, 1024px).
7. Cross-browser: Chrome, Firefox, Safari desktop plus twee mobile-browsers.
8. SEO-elements check: title tags, meta descriptions, canonicals, robots.txt, XML sitemap, geen noindex overgebleven van staging-defaults.
9. Structured data verify: Schema.org markup via Google Rich Results Test en Schema Markup Validator.
10. Klant-acceptatie: 24-uurs review-window voor de klant met een concrete checklist. Zonder ondertekende go-ahead ga ik niet live.

Voor de curl-redirect-test gebruik ik dit bash-scriptje. Het werkt 50 tot 500 URLs uit een CSV af:

#!/bin/bash
# redirects-check.sh
while IFS=, read -r oude nieuwe; do
    status=$(curl -o /dev/null -s -w "%{http_code}" -I "$oude")
    location=$(curl -sI "$oude" | grep -i "^location:" | awk '{print $2}' | tr -d '\r')
    echo "$oude -> $status -> $location"
done < redirects.csv

Zie je iets anders dan “301”, dan zit er een bug in je redirect-map. Ook een verkeerde target-URL fix je vóór go-live.

Fase 10: go-live cutover (roadmap 3, met timing per site-size)

Cutover-timing hangt af van site-omvang en publiek. Een blog kun je op donderdagochtend 10 uur live zetten. Een WooCommerce-shop met €5.000 dagomzet doe je op zondagnacht 02:00, met alle stakeholders paraat.

Timing per site-omvang:

Voor de DNS TTL geldt een strikte regel: verlaag de TTL minimaal 24 tot 48 uur vooraf. Staat je huidige TTL op 3600 seconden (1 uur), dan ga je 24 uur voor de cutover naar 300 seconden. Alle DNS-caches wereldwijd switchen dan binnen 5 minuten mee. Verlaag je pas 1 uur voor cutover, dan houden caches nog een uur de oude waarde vast. Je zit dan met een halve situatie.

Go-live checklist (12 stappen):

1. T minus 30 min: laatste backup productie via JetBackup, Kinsta snapshot of wp db export.
2. T minus 20 min: productie in maintenance-mode. Bij WordPress: WP Maintenance Mode plugin, of maak een .maintenance file in de root met .
3. T minus 10 min: content-delta sync voor nieuwe orders en opmerkingen sinds de laatste staging-snapshot.
4. T=0: DNS-switch bij domainregistrar. TTL staat al 24 uur op 60–300s.
5. T plus 5 min: DNS-propagation checken via whatsmydns.net op minimaal 10 locaties wereldwijd.
6. T plus 10 min: cache invalidate. Cloudflare “Purge Everything”, LiteSpeed “Clear All Cache”, Redis flush indien van toepassing.
7. T plus 15 min: SSL-cert verify op nieuwe site. Auto-provisioning via Let’s Encrypt kan 5 minuten duren.
8. T plus 20 min: smoke-test top-20 URLs manueel doorlopen.
9. T plus 25 min: payment-gateway van sandbox naar live keys omzetten. Mollie en Stripe hebben aparte test/live API-keys.
10. T plus 30 min: maintenance-mode uit.
11. T plus 35 min: real transaction test. €0,01 iDEAL-order via je eigen account, met refund achteraf.
12. T plus 40 min: klant informeren dat site live is. Verstuur een korte samenvatting met eventuele known issues en de post-migration monitoring-planning.

Grotere sites willen tijdens de cutover geen bezoekers op het bestelscherm hebben. Cloudflare Waiting Room (Business en Enterprise plans) zet alle traffic dan in een virtuele wachtrij. Op lager-tier plans gebruik je de simpelere Cloudflare maintenance mode via Workers of Rulesets.

Fase 11–12: post-migration verify (roadmap 4)

De eerste 48 uur na go-live zijn kritiek. Dit is wanneer Google je nieuwe site het intensiefst crawlt en wanneer 90 procent van eventuele problemen zich manifesteert.

48-uurs verify-roadmap:

1. GSC nieuwe sitemap submitten: via Google Search Console → Sitemaps → voeg /sitemap.xml toe voor het nieuwe domein.
2. GSC Change of Address (alleen bij domein-rebrand): via Settings → Change of Address tool. Google raadt aan om variants (www en non-www) én subdomains apart in te dienen. De notificatie blijft 180 dagen zichtbaar.
3. Nieuwe crawl via Screaming Frog: check dat alle top-URLs 200 status geven, geen 500-errors, geen redirect-chains langer dan 2 hops.
4. Redirect-verify sample: 100 willekeurige oude URLs, verwacht 301 naar correcte nieuwe URL.
5. GSC Coverage report: eerste re-indexing-signalen komen binnen 24–48 uur op de nieuwe URLs. Bij een domein-rebrand kan dit 7 dagen duren.
6. GA4 real-time users: moet in dezelfde bandbreedte zitten als pre-migratie baseline (±10 procent op vergelijkbare weekday/tijdstip).
7. Mail-deliverability: test contactform, transactionele mails (order-confirms), password-reset. Vaak vergeten na hosting-move omdat SPF/DKIM opnieuw gezet moeten worden.
8. Payment-gateway logs: Mollie dashboard, Stripe dashboard. Check dat webhooks binnenkomen op de nieuwe URL.
9. Server-logs check op 5xx errors: tail -f /var/log/nginx/error.log of via hostingpaneel.
10. Uptime-monitor: Better Uptime, UptimeRobot of Pingdom moet nieuwe URL kennen en positief rapporteren.

30-dagen monitor-roadmap:

1. Wekelijkse GSC Performance-check: clicks en impressies vergelijken pre en post per week. Verwacht een dip in week 1, herstel vanaf week 2.
2. Rank-tracking top-20 keywords: Ahrefs Rank Tracker (Lite-plan vanaf $129/maand), Semrush Position Tracking (Pro-plan vanaf $139,95/maand), of AccuRanker daily rank check.
3. Backlink-monitoring: worden oude URLs nog gelinked door externe sites? Add extra redirects indien nodig. Google raadt aan redirects minimaal 1 jaar aan te houden, in de praktijk hou ik ze permanent.
4. GA4 conversion-tracking verify: doelen, e-commerce events, GA4 naar GTM koppelingen. Vaak vergeten dat GTM-container opnieuw goedgekeurd moet worden op de nieuwe domain.
5. Klant-feedback loop: wekelijkse call eerste 4 weken. Klein en frequent werkt beter dan groot en zeldzaam.
6. Second GSC sitemap-submit als re-indexing-signalen zwak blijven na 14 dagen.
7. Documentatie afronden: één A4 voor klant met wat er precies is gebeurd, welke plugins zijn toegevoegd of verwijderd, waar backups staan, en de rollback-instructies voor eventuele problemen.

Post-migration verify-metrics-tabel:

Als je na 30 dagen nog onder 95 procent op GSC clicks zit, dan is er iets fundamenteels stuk. Check missing redirects, canonical-issues, gebroken structured data, of robots.txt die de nieuwe site alsnog blokkeert. Terug naar fase 8.

Rollback-scenario en wanneer terugdraaien (roadmap 5)

Niet elke haperende migratie hoeft teruggedraaid te worden. Bij een 404-error op één pagina fix je vooruit, geen rollback. Bij een gebroken checkout die 12 uur duurt om te fixen, wel. Deze matrix gebruik ik als drempelwaarde:

Rollback-protocol (max 2 uur, mits pre-migration voorbereiding klopt):

1. Maintenance-mode aan op de live (nieuwe) site.
2. DNS-switch terug naar oude host. TTL is nog steeds 60–300s omdat je die niet meteen weer verhoogde.
3. Wacht DNS-propagation: check via whatsmydns.net.
4. Restore backup van pre-migratie snapshot op oude host. Bij Kinsta of WP Engine is dit een 1-klik-actie, bij DIY-VPS via wp-cli db import en tar xzf uploads.tar.gz.
5. Cache invalidate overal (Cloudflare purge, LiteSpeed clear, browser-cache).
6. Smoke-test top-20 URLs en de checkout-flow.
7. Klant informeren en incident post-mortem plannen binnen 24 uur.

Deze zeven stappen kun je in circa 90 minuten uitvoeren als de backup vers is en de DNS TTL laag stond. Als je de backup nooit hebt getest of TTL nog op 3600 stond, ben je een halve dag verder en verlies je meer verkeer dan de originele migratie-issue kostte.

Per-hostingpaneel migratie-specifieke stappen

Elk hostingpaneel heeft een eigen aanpak voor de fysieke datamigratie. Dit zijn de meest gebruikte panelen in Nederland en België.

DirectAdmin (Antagonist, Vimexx, mijn.host): JetBackup 5 snapshot als pre-migratie backup, Softaculous WordPress “Clone” voor de staging-naar-live push, en File Manager voor eventuele handmatige file-swaps. Zie de hosting-migratie zonder downtime gids voor het complete cPanel-recept.

Plesk (Argeweb, en op VPS bij TransIP en Combell): Backup Manager plus WordPress Toolkit “Clone” functionaliteit. Plesk Migrator kan complete accounts overzetten tussen Plesk-servers, wat ik veel gebruik bij TransIP-naar-Combell moves.

cPanel (o.a. Neostrada): SystemBackup2 module voor snapshots, plus DirectAdmin’s ingebouwde “Site Migration” tool voor DA-naar-DA moves.

Hostinger hPanel: Automatic Migration tool (gratis) voor incoming migraties, plus dagelijkse backups met 7-dagen retentie.

Cloudways: eigen Migrator plugin (gratis) via MalCare tech, plus 1-klik staging environments per applicatie.

Kinsta: dev/staging/live workflow met push-to-live via MyKinsta dashboard. Dagelijkse backups standaard, 14–30 dagen retentie afhankelijk van plan.

WP Engine: Local WP Blueprints voor lokale development plus WP Engine’s own migration plugin voor incoming sites. Automatic backups met 40 dagen retentie op alle plans.

DIY VPS (RunCloud, ServerAvatar, GridPane): rsync over SSH voor bulk file-transfer, WP-CLI voor DB export en import. Voorbeeld voor rsync:

# Van oude naar nieuwe server via SSH
rsync -avz --progress -e ssh \
    /var/www/html/wp-content/uploads/ \
    user@new-server:/var/www/html/wp-content/uploads/

# Database dump plus import (streamed via SSH pipe)
wp db export - --extended-insert=false | \
    ssh user@new-server "cd /var/www/html && wp db import -"

Kosten-inschatting migratie per site-type

Klanten willen altijd weten wat een migratie kost voordat ze committen. Dit is de range waar ik in mijn praktijk uitkom, gebaseerd op circa 40 migraties in de laatste twee jaar.

Downloadable checklist (met afvinkkolom)

Deze checklist gebruik ik als eindcontrole. Voor de klant is het het afvinkdocument bij oplevering. Kopieer hem naar je eigen document en werk hem door.

HSTS en HTTPS-migratie: caveat om te kennen

Bij een HTTP-naar-HTTPS-migratie is de verleiding groot om meteen op de HSTS preload list te submitten. Doe dat niet direct. HSTS preloading is nauwelijks meer aanbevolen sinds moderne browsers HTTP-navigaties standaard upgraden naar HTTPS. Belangrijker: rollback is bijna onmogelijk. Removal van de Chromium preload list duurt 4 tot 12 weken voor integratie, plus 6 tot 12 maanden voor browser-adoptie. Sommige users zien de removal nooit.

Praktisch: activeer wel de HSTS-header met een korte max-age (bijv. max-age=300) om te testen, verhoog geleidelijk naar max-age=31536000 (1 jaar), en submit preload pas na 3 maanden stabiel HTTPS-only draaien. Voor de meeste MKB-sites is preload sowieso overkill.

Peppol/UBL post-migratie: extra check voor webshops

Voor Nederlandse webshops geldt sinds 2026 een groeiende druk richting Peppol-based B2B-facturatie, waarbij de EU-ViDA deadline op 1 juli 2030 ligt. België verplicht Peppol al per 1 januari 2026 voor B2B-invoices. Zie peppol.nu voor de meest recente Nederlandse regels en accreditatie.

Praktisch: als je klant een webshop heeft met B2B-facturen naar Belgische afnemers, controleer na de migratie of de UBL-export nog werkt en dat de Peppol-integratieplugin (bijv. WooCommerce Peppol Extension of YITH Invoices met UBL-add-on) mee is gemigreerd en de correcte KVK/BTW-nummers gebruikt. Add dit als item 8 in de 48-uurs verify-roadmap voor webshop-migraties.

Wanneer een specialist inhuren

Doe je migratie zelf als:

1. Je een statisch blog of MKB-brochure hebt zonder live orders.
2. Je comfortabel bent met DNS-panelen, WP-CLI, en al minstens één keer eerder een staging-omgeving hebt gebruikt.
3. Je een geverifieerde 3-2-1 backup hebt en de rollback-procedure hebt getest.
4. Je 40 tot 80 uur beschikbaar hebt in de kalenderperiode.

Bel een specialist in als:

1. Je een WooCommerce-shop met dagelijkse orders hebt.
2. Je een membership-site of LMS draait met tientallen tot honderden gebruikers.
3. Je site meer dan 10.000 backlinks heeft en link-equity-verlies onacceptabel is.
4. Je een domein-rebrand doet waarbij brand-search-verkeer meer dan 20 procent van je totale verkeer is.
5. Je AVG-plichtig bent (klantdata, medische data, financiële data) en migratie-audit-trail vereist is.

Voor mijn eigen praktijk: minimum 30 uur werk voor een reële migratie, meestal 40 tot 80 uur inclusief 3 rollback-drills op staging. Klant uit Antwerpen met 40k-orderarchief en 6-jarige backlink-history kostte 92 uur, oftewel €8.740 inclusief documentatie en drie post-live monitoring-weken. Vergelijk dat met de €18.000 orderverlies uit de eerder genoemde Middelburg-case, en het rekensommetje is snel gemaakt.

Vast met een migratie of overweeg je uitbesteding?

Loop je vast in een van deze fasen? Of heb je een WooCommerce- of membership-shop waarbij je geen risico wilt lopen? Stuur me een mail via /contact/. In een intake-call van 20 minuten bepaal ik samen met jou welk migratie-scenario van toepassing is. Daarna krijg je binnen 48 uur een uren-inschatting. Het cutover-moment plan ik in met bufferruimte voor rollback.

Tarief blijft €95/uur, geen abonnement, geen minimumafname. Zie /diensten/ voor een compleet overzicht van wat ik uit handen kan nemen. Voor een specifiek migratie-scenario: kies uit de spoke-artikelen aan het begin van deze gids om direct de juiste sub-workflow te lezen.