Move for a testable reason
Drupal 7 has been end-of-life since 5 January 2025, but that does not make WordPress a universal answer.
Maintenance, hiring, editing or custom-module costs may justify the move. We write those reasons down before selecting the technology.
Complex workflows, permissions and content models must prove they can live in WordPress without creating another fragile plugin stack.
- Support and security
- Team capability
- Editorial complexity
- Dependency cost
Map models, not screens
A Drupal type with fields and taxonomies does not correctly become a generic WordPress post.
Every type, field and relationship receives a native or controlled WordPress destination.
Rejected content is reported. A migration marked “complete” while silently dropping fields has failed.
- Types and fields
- Taxonomies and relationships
- Media and alt text
- Users and roles
Keep addresses with history
Drupal aliases can stay or redirect to an equivalent destination.
We export URLs before migration and compare them with WordPress output. Redirects are direct and internal links already use the new addresses.
Languages retain distinct URLs and reciprocal alternates. Sending everything to one language breaks the route.
- Alias inventory
- Old → new register
- No redirect chains
- Reciprocal hreflang
Prove it with a difficult pilot set
A representative sample contains exceptions, not only three news posts.
We migrate a rich page, public and private file, relationship, form, account and multilingual entry. Source and destination counts, orphaned files, permissions and account access are reconciled.
The pilot uses fictitious or anonymised data. Full cutover follows editing, search, form, indexing and rollback tests.
The pilot is rerun incrementally with a high-water mark or change tracking. We name the writer, drain jobs and webhooks, briefly freeze editing and reconcile the final delta.
Rollback is safe only while the target remains read-only or new writes can sync back to the source. Reverting DNS does not restore data.
- Source and destination counts
- Private and orphaned files
- Accounts and permissions tested
- Difference report
- Timed rollback
- Idempotent incremental imports
- Freeze and final delta
- Drain jobs and webhooks
- Reconciliation or reverse sync
Keep both versions compatible during the move
An editorial freeze is not enough while an old worker can still read what the new target writes.
Jobs, messages and cache values carry a versioned schema or namespace. Old Drupal and new WordPress read the formats produced during overlap and rollback; an incompatible message is isolated instead of poisoning the queue.
Database and private-file backups are decrypted in both directions with the real KMS keys, grants and context. Outbound connections, allowed IPs and mTLS certificates are tested from the production target.
Before Drupal leaves the load balancer, readiness checks the database, media, search, forms and login. New requests stop, uploads and persistent connections drain, and time synchronisation protects tokens, signatures and jobs.
- Schemas and caches readable by both versions
- Target and rollback decryption
- Integrations tested from production IPs
- Functional readiness and connection draining
Decide before cutover
Drupal to WordPress, without a blind copy
- Complete Drupal inventory
- WordPress model approved
- Pilot compared
- URLs and languages tested
- Proprietary plugins identified
- Delta and data rollback tested
- Old ↔ new compatibility proven
- Encrypted restore executed
- HTTP draining timed
Official sources