WordPress content and data migration
A migration is judged months later, by what turned out to be missing. We treat it as an engineering task with a verifiable result: a complete inventory before anything moves, scripted transfers that can be run repeatedly against staging, and a redirect map that is tested rather than assumed.
- A full inventory of URLs, content types, media and search performance first
- Scripted and repeatable, so the final run is the tenth run, not the first
- A complete redirect map: one hop, no chains, kept permanently
- Reconciled after launch against the inventory it started from
What we migrate
Onto WordPress from another CMS
Drupal, Joomla, proprietary and home-grown systems, or a static site. The work is mostly in mapping a foreign content model onto one designed for the organization rather than replicated from the old system’s quirks.
Between WordPress builds
From an ageing theme and plugin stack to a new architecture, usually as part of a modernization. Content moves into a new model, which is the part that needs care.
Consolidating several sites into one
Multiple properties merged into a single site or a multisite network, with overlapping content reconciled and competing URLs resolved deliberately rather than by accident.
Between hosts and infrastructure
Moves onto cloud or managed infrastructure, including environment configuration, DNS cutover planning and a rollback position.
Structured data and records
Directories, catalogues, member and document databases imported into a designed content model, with fields mapped, values normalized and duplicates resolved.
Large media libraries
Documents, images and video moved with their metadata, references rewritten, and orphaned files identified rather than silently dropped.
How a migration is actually kept honest
Most migration failures are discovered too late to be cheap: a content type that never came across, a decade of PDFs whose links now 404, a redirect map that covers the navigation but not the deep pages that were earning the traffic. All three are avoidable, and all three are avoided by counting things.
Inventory first
Every URL, content type, media file and its search performance, exported before design or development begins. The inventory is the specification for the migration and the checklist it is verified against.
Model the destination
Content is migrated into a model designed for the organization, not into a replica of the old system’s structure. This is the opportunity a migration creates, and skipping it means carrying old problems forward.
Script everything
Migrations are code, run against staging as often as needed. Manual copying does not scale, is not repeatable, and is where content goes missing without anyone noticing.
Map every URL
Old to new for the entire inventory, resolving in a single hop. Pages that are genuinely retired redirect to the most relevant surviving page rather than to the homepage.
Rewrite internal links
Links inside migrated content are rewritten to their new destinations, so the site is not held together by its own redirect table.
Reconcile and verify
Counts compared against the inventory, a full crawl for 404s and chains, and search and analytics watched against a pre-migration baseline for the weeks that follow.
Moving a site, or moving onto WordPress?
Tell us what is moving, where from, and what must not break. The inventory stage is short, and it is what turns a migration estimate into something worth relying on.
What you receive from a migration
A migration is the one project where the deliverable is mostly evidence. These are the artefacts the work produces, and they are what make it checkable by someone who was not in the room.
The inventory
Every URL, content type, media file and its search performance, as an exported spreadsheet. It is the specification for the migration and the checklist it is verified against afterwards.
The redirect map
Old address to new for the entire inventory, one hop each, with a documented decision for anything retired. Yours to keep, and to hand to whoever runs the platform next.
The reconciliation report
Counts from the source against counts at the destination, per content type, with anything that did not move listed and explained rather than absorbed.
The crawl report
A full post-launch crawl for 404s, redirect chains and broken internal links, run against the old inventory rather than against the new sitemap.
Migration is where search visibility is most at risk
An organization with fifteen years of content has an acquisition channel built out of URLs that other people link to and search engines have already ranked. A migration is the single most dangerous event in that channel’s life, and the damage is usually done by decisions that looked like tidying up: shortening a URL structure, consolidating pages that had different intents, retiring an old section that quietly held the deepest links.
We export search performance per URL as part of the inventory, so the pages that are actually earning visibility are visible to everyone making structural decisions. Where such a page has to move, it is a decision with a cost attached rather than a detail of the sitemap. Redirects go live with the launch, never afterwards, and stay in place permanently.
Frequently asked questions
-
Will a migration cost us our search rankings?
It can, and the causes are mostly decisions rather than accidents: changing URLs without a complete redirect map, chains instead of single hops, retiring pages that were quietly earning visibility, and rewriting a structure nobody checked against real search data. We export search performance per URL as part of the inventory so those pages are visible to everyone making structural decisions, redirect in one hop where a move is necessary, and watch the weeks after launch against a baseline captured before it. Nobody can promise a position in the results. What is available is the removal of the avoidable reasons a migration loses one.
-
How long does a migration take?
Content volume matters less than content variety. Ten thousand pages of one type is a smaller job than two thousand across nine types with inconsistent fields. The inventory stage is short and it is what turns an estimate into a number worth relying on, so it is usually the first thing we do.
-
Can you migrate from Drupal, Joomla or a system nobody supports any more?
Yes. Those are ordinary sources. The work is rarely in extracting the data, it is in mapping a foreign content model onto one designed for your organization rather than replicating the old system’s quirks into a new database. Where a system has no export, content can be taken from the rendered site itself.
-
Do we have to freeze content while it runs?
Only briefly, and at the end. Because the migration is scripted it can be re-run, so editors keep working while it is developed and tested. A short freeze before the final run keeps the reconciliation honest, and it is measured in hours rather than weeks.
-
What happens to our PDFs and documents?
They move with their metadata, and the references to them are rewritten. Document libraries are where migrations most often lose things quietly, because nobody notices a PDF is missing until somebody needs it. Orphaned files are listed rather than deleted, so retiring them is a decision.
-
Is a migration a good time to restructure the site?
It is the only cheap time, which is why we model the destination rather than replicate the source. It is also the moment structural risk is highest, so restructuring is done against the search and traffic data in the inventory rather than against an org chart. If the site also needs a new design, that is a modernization and the two run as one project.