Drupal to WordPress
Drupal to WordPress Migration for Sites Nobody Wants to Maintain
Move a Drupal site to WordPress when nobody left can maintain it. Drupal migrations are usually inherited rather than chosen - a version gone end-of-life, a developer who moved on - and the work is mapping content types and taxonomy onto WordPress without losing either. Send the address for a written transfer plan.
Roughly what will this cost?
An estimate from the three things that actually drive the price. A fixed quote follows a look at the site.
Get a fixed quote- Content types mapped to post types, not flattened into pages
- Taxonomy preserved, which is where most Drupal moves lose structure
- Every node URL and path alias redirected, one hop
- A platform your team can actually edit without a developer
What transfers, what gets rebuilt
| What | Comes across | Needs rebuilding |
|---|---|---|
| Nodes | Yes | Mapped to post types rather than dumped into pages |
| Content types and fields | Yes, as custom post types and fields | The field structure, deliberately |
| Taxonomy | Yes | Hierarchy and term relationships, checked by hand |
| Files and images | Yes | Media library structure |
| Path aliases | No | A redirect for every alias, and for the /node/ form |
| Views | No | Rebuilt as queries or archive templates |
| Users | Yes, without passwords | Roles mapped to WordPress capabilities |
| Custom modules | No | Assessed individually; some have no equivalent |
Inherited, not chosen
Few people set out to leave Drupal. They arrive at it: the version went end-of-life, the agency that built it moved on, and the last person who understood the theme layer left two years ago.
That shapes the job. The site usually still works, the content is usually good, and the problem is that nobody can safely change anything. An unsupported Drupal is also a security exposure of a specific kind – a widely-deployed CMS with published vulnerabilities and no patches coming – which is different from a merely neglected site.
So the move is about maintainability rather than capability, and the measure of success is whether your team can edit the site afterwards without calling anyone.
Taxonomy is where these go wrong
Drupal’s content model is more expressive than WordPress’s defaults, and the tempting shortcut is to flatten it – every node becomes a page, every term becomes a category, and the structure that made the content navigable disappears.
Content types become custom post types. Fields become fields. Vocabularies become taxonomies, with the hierarchy checked by hand rather than assumed, because term relationships are the part that silently does not survive an automated import.
The URL side has its own trap: Drupal answers on both a path alias and a raw /node/<id> address, and search engines have often indexed both. The redirect map covers both forms, or a proportion of the site’s positions land on a 404. The full sequence is in the WordPress migration checklist.
Where this sits among the others
Drupal migrations fail on modelling rather than on data: the nodes arrive and the structure that made them navigable does not. The same failure shows up moving from Umbraco to WordPress, where document types collapse the same way, and from Magento to WooCommerce, where it is attribute sets rather than content types.
The order of work is common to all three and is written out on WordPress migration service. The reason these sites reached this point is usually that nobody was maintaining them, which is the problem price and package on WordPress service exists to prevent recurring.
How the work runs
- Inventory the old siteEvery URL, every page, every product, every form. The export is checked against a crawl, because platform exports routinely omit what was never a page - landing URLs, redirects already in place, files linked directly.
- Build on WordPress firstContent types, templates and the theme are stood up and populated before anything points here. The old site keeps trading throughout.
- Map every URLOld address to new address, one hop, written down before the switch rather than discovered from 404s afterwards.
- Test what earns moneyForms, checkout, search, login. A migration that moves every page and breaks the enquiry route has failed at the only thing it was for.
- Switch, then watchDNS moves with the TTL already lowered. Real 404s are checked against the redirect map for a fortnight, and the old platform stays paid for until it is provably unnecessary.
The redirect plan
- Export every path alias, plus the raw /node/ URLs both forms answer on
- Map aliases to the new permalink structure, one hop
- Redirect /node/ to the same destination as its alias
- Map taxonomy term pages, which carry positions on larger Drupal sites
- Map file paths under /sites/default/files/
- Publish as server-level 301s and verify no chains
- Re-crawl and reconcile real 404s for a fortnight
Plans that include this
- Starter$39/monthor $390 a year — two months freeBlogs, portfolios and brochure sites
- UpdatesMonthly
- BackupsWeekly, 30-day retention
- Uptime5-minute checks
- Malware removalNot included
- Most chosenProfessional$79/monthor $790 a year — two months freeSmall businesses and lead-generation sites
- UpdatesWeekly + PHP version management
- BackupsDaily, 60-day retention
- Uptime1-minute checks
- Malware removalIncluded
- Business$149/monthor $1490 a year — two months freeStores, membership sites, anywhere downtime costs money
- UpdatesWeekly, tested on staging first
- BackupsDaily, 90-day, multi-location
- Uptime1-minute + 2-hour restore
- Malware removalIncluded
The service that covers this
wordpress migration serviceMove a WordPress site to new hosting without the outage everyone expects. The new install is built and tested while the old one keeps serving, DNS…
More in Migration
Questions people ask before calling
My Drupal version is end of life. Is that urgent?
Yes. An unsupported Drupal gets no security patches, and known vulnerabilities in a widely-deployed CMS are scanned for continuously. That is a different risk from an ageing site nobody has touched.
Will my content structure survive?
It is the thing we protect hardest. Content types become post types and fields become fields; the mistake is flattening everything into pages, which loses the structure that made Drupal worth using.
What happens to Views?
They are rebuilt as WordPress queries and archive templates. This is usually the largest single piece of work, and it is scoped during the inventory rather than discovered.
Can my team edit WordPress?
That is generally the reason for the move. The editorial experience is the main thing people gain, alongside a much larger pool of people who can maintain the site.
What about custom modules?
Each is assessed. Some map to a plugin, some to a small amount of custom code, and occasionally something has no equivalent and the requirement gets re-examined. None of that should be a surprise after the switch.