Two specialists arranging page inventories and a redirect map before a website migration

Website migration · Belgium

Migrate the website, not the problem

WordPress, Drupal, another CMS or a new domain: we inventory URLs, content and functions before choosing the destination.

On this page

Name the kind of migration first

Hosting, CMS, domain and architecture changes carry different risks.

If URLs stay the same, the work centres on files, databases, certificates, forms and scheduled jobs. If they change, every old address also needs an explicit destination.

Launching a new CMS, domain and design together blends three possible causes of failure. Google recommends separating major changes when the project allows it.

  • Hosting with stable URLs
  • New CMS
  • New domain
  • Merge or split websites

Inventory what must survive

A migration is not simply a page copy.

We collect indexed URLs, content, files, languages, forms, accounts, permissions, automations and external connections.

Tests use fictitious or anonymised data. Staging access, temporary copies, retention and deletion are recorded before the first production export.

  • Pages and media
  • Data and relationships
  • Users and permissions
  • Anonymised test copies
  • Export access and deletion

Choose the destination after diagnosis

WordPress is not automatically simpler and Drupal is not automatically too heavy.

The right foundation depends on content models, roles, languages, integrations and the people who will maintain it.

A representative pilot proves more than ten meetings: one complex page, form, media item, language and redirect expose the real route.

  • Representative sample
  • Team editing workflow
  • Maintained dependencies
  • Explicit ownership cost

Cut over, measure and repair

Launch is a checkpoint, not the finish line.

Before opening, we test redirects, canonicals, robots.txt, sitemaps, forms and events.

The DNS zone is exported and reviewed: web, MX, SPF, DKIM, DMARC, subdomains, TTL and DNSSEC. A load test covers both the new site’s normal crawl and visits redirected from the old site; latency, 429, 5xx and WAF blocks have written rollback thresholds.

The dependency register covers CORS, CSP, OAuth, webhooks, cookies and local storage: a new domain is a new browser origin. Consent starts denied again; only an explicit, signed, single-use functional handoff may carry a draft.

One system remains the named writer. Incremental imports, a short final freeze, the last delta and reconciliation of jobs and webhooks precede cutover; data rollback needs reverse synchronisation, not merely DNS.

  • Rollback plan
  • Direct 301s
  • DNS zone and email
  • Capacity and logs on both servers
  • Post-launch checks
  • A and AAAA, CAA, TLS and HSTS
  • CORS, CSP, OAuth and webhooks
  • Consent and origin-scoped storage
  • Final delta and reverse sync

Close invisible access paths before cutover

A page responding does not prove that the right network, cache or key is responding.

Outbound connections are replayed from the target with its real IP addresses. Firewalls, allowlists and mTLS client certificates are validated with every external service. DNS is queried from the internet, VPN, office and service networks so that a private zone cannot keep pointing at the old server.

When a CDN or reverse proxy is added, only those relays can reach the origin. The trust chain for Forwarded, X-Forwarded-For, Host and Proto is tested against spoofing. Apps and partners that pin a certificate or public key receive the new pinset before rotation.

The target receives traffic only after data, media, forms and connections pass functional readiness. The old backend stops receiving new requests and drains uploads and persistent connections. Both clocks are synchronised and monitored before JWT, signature, TLS and scheduled-job tests.

The register separates origin-scoped web storage from cookies, which are scoped by name, Domain, Path and SameSite. Host-only or __Host- cookies prevent the two versions overwriting each other. Third-party scripts and tag containers record an owner, version, data and destinations and remain frozen during acceptance.

During overlap, old and new workers read both message and cache-value versions; schemas and namespaces are versioned. An encrypted restore is actually decrypted in target and rollback environments with the expected KMS keys, grants and context. Non-HTML documents receive their canonical Link header, and each language keeps a crawlable URL with a correct cache key or Vary.

  • Outbound IPs, allowlists and mTLS certificates
  • Public and private DNS resolvers
  • Trusted proxy headers and a locked origin
  • Pinsets, readiness, draining and clock sync
  • Cookie scope and frozen tag containers
  • Message schemas, caches and KMS keys
  • HTTP canonicals for PDFs and language-aware caching

Register domain-bound identities and permissions again

A redirect moves a visit, not the trust granted to the old origin.

Camera, microphone, geolocation, payment and fullscreen are tested on the new origin. Permissions-Policy allowlists and iframe allow attributes explicitly name the new domains. For FedCM, the identity provider registers the exact new relying-party origin and verifies its Origin header; the provider web-identity file remains available.

Enterprise login moves as a contract: Entity ID, ACS URL, logout URL, metadata and SAML certificates remain valid on both versions during transition. The SCIM base URL, tokens, Users and Groups routes are tested through creation, update, deactivation and deletion so ghost accounts cannot remain.

If the site takes Apple Pay, every merchant domain publishes its association file and is verified before cutover, with TLS expiry monitored. CSP reporting moves too: report-to and report-uri target a live collector and are exercised because report-to takes precedence when both exist.

  • Browser permissions and iframes by origin
  • FedCM registered for the new origin
  • SAML and SCIM tested through deactivation
  • Apple Pay verified when present
  • CSP reports received by the target

Decide before cutover

Which migration route fits your site?

  1. Migration type named
  2. Inventory exported
  3. Test data anonymised
  4. Pilot migrated
  5. URL mapping approved
  6. DNS, email and capacity tested
  7. Cutover owner assigned
  8. Domain-bound dependencies tested
  9. Data continuity plan approved
  10. Origin unreachable outside the CDN
  11. Internal and external DNS compared
  12. In-flight connections drained
  13. Cookies and third-party tags inventoried
  14. Encrypted restore proven
  15. PDFs and languages tested with cold and warm caches
  16. Permissions and FedCM replayed on the new domain
  17. SSO and SCIM deprovisioning proven
  18. Apple Pay and CSP reporting checked when applicable

Official sources

Google · site moves with URL changesWordPress · migrating a siteGoogle · generative AI performanceGoogle · generative AI inclusion controlGoogle · optimizing for generative AIBing · AI PerformanceGoogle · cross-domain measurementIndexNow · protocolGoogle · Organization structured dataVercel · configure CORSLet’s Encrypt · IPv6Let’s Encrypt · CAAMDN · TLS and HSTSWHATWG · origin-scoped web storageDrupal · Migrate API and change trackingDrupal · upgrading from Drupal 7Drupal · supported versions and scheduleCNIL · personal data in test environmentsCloudflare · review DNS before migrationEDPB · controller and processor dutiesGoogle Cloud · static outbound IPOWASP · mutual TLSMicrosoft · hybrid and split DNSCloudflare · HTTP proxy headersCloudflare · authenticated origin pullsOWASP · certificate and public-key pinningGoogle Cloud · connection drainingMicrosoft · functional health endpointsGoogle Cloud · time synchronisationMDN · cookie scopeConfluent · schema evolution and compatibilityAWS · backup encryptionGoogle · canonical HTTP header for documentsGoogle · locale-adaptive pagesMDN · Vary response headerOWASP · third-party JavaScriptW3C · origin-based Permissions PolicyChrome · FedCM for identity providersMicrosoft · SAML Entity ID and ACS URLIETF · SCIM protocolApple · verify merchant domainsW3C · CSP reporting

Your project · 02:00

Turn this reading into a concrete quote.

Choose what you need. The configurator prices the website without a meeting or forced follow-up.