Moving a site into WordPress, or rebuilding the one you have
A move between servers keeps the software the same and changes where it runs. This is the other thing: changing what the content lives in. The content model is the real work, and the URLs are what the move puts at risk.
Every content type becomes a decision
The old CMS has a content model — possibly a bad one, possibly implicit, possibly three of them layered over each other after previous moves. WordPress has posts, pages, taxonomies and custom fields. Getting from one to the other means deciding what each existing type becomes, and that decision determines the URLs, the templates and what editors can do afterwards. Migrating the data without making the decision produces a WordPress site that is hard to publish on.
- The current CMS is being retired, has become unmaintainable, or licenses have become untenable
- Editorial work depends on a system nobody wants to keep supporting
- The site has been through earlier migrations and carries several content structures at once
- The URLs need to survive the move and nobody has a complete list of them
- Content lives in several places — a CMS, a custom database, files — and has to be reconciled
- The rebuild is wanted in place rather than as a lift-and-shift
- The site has to keep publishing during the move
- A previous migration lost content or search visibility and the same must not happen again
The people who usually bring us this problem
A site moving from another CMS to WordPress
You want the content and the URLs to arrive intact and a publishing experience that is better than the one you are leaving.
A WordPress site being rebuilt
The platform is right and the implementation is not — the content model, templates or editing experience need rebuilding.
Someone with content in more than one place
The estate is a CMS plus a bespoke database plus files, and the migration is partly a reconciliation.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
The content model is the decision that outlives the project
How content is modelled determines the URLs, the templates, what editors can publish without help and how hard the next change is. It is the one part of a migration that is expensive to revisit, and it is usually decided late because it looks like a technical detail.
URLs are the content's public identity
Every address that exists is linked from somewhere, indexed by a search engine, or both. A migration that changes addresses without mapping them discards what the site accumulated, and the loss is gradual enough to be attributed to something else.
Content that does not fit the new model gets quietly lost
It is rarely deleted — it arrives in a generic field, or as an unstructured block, or not at all. The pages where it happened are the ones nobody visits, which is why the loss surfaces months later.
A rebuild in place is a migration with a smaller diff and the same risks
The platform stays and the content model, templates and URLs change anyway. It is sometimes treated as a theme job, which is why it more often ends in a broken URL structure than a platform move does.
Capabilities
Each of these is work we carry out, not an area we advise on.
Content model design for WordPress
Deciding what each existing content type becomes — post type, taxonomy, template and field structure — before anything is migrated. This is the design work the rest depends on, and it is done with the people who publish rather than for them.
Content extraction and reconciliation
Getting the content out of the existing system, including from bespoke databases, static files and any structure left by an earlier migration. Content in several places is reconciled rather than concatenated.
Content mapping and transformation
Every existing field to a destination field, including the ones with no destination. Where content does not fit, that is found during mapping and decided then — as a field, a conversion, or a deliberate omission recorded as one.
URL inventory and redirect strategy
Establishing what addresses the site currently serves and mapping them to the new structure by class, activated with the cutover rather than after it. This is the difference between keeping search visibility and hoping to.
Media migration and reference rewriting
Attachments, embedded media and the references between content. WordPress records its own paths for media, so a migration that moves files without rewriting every in-content reference produces a site that looks right and has no images.
Template and editing experience
Themes and templates built for the new content model, and an editing experience that reflects it — so the structure that was designed is the structure editors actually work with, rather than one they work around.
Search visibility protection
Inventory and baseline before, redirects and sitemaps at cutover, and crawl and indexation monitoring afterwards. A platform move is a search event whether or not anyone treats it as one.
Staged cutover and rollback
Content migrated and verified ahead, the cutover covering only what changed, with a rehearsed rehearsal on real data and a tested return path. Publishing continues throughout, because a migration that stops publishing costs more than it saves.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Model the content before migrating any of it
Every content type decided, with the people who publish. Migrating first and modelling afterwards produces a WordPress site whose structure is a copy of the old system's accidents, which is often the reason the old system was being left.
Inventory the URLs before designing the new structure
What exists, in every pattern the site has used, decided before the new URLs are chosen. It is the only way to know what the redirect map has to cover, and on a site with migration history there are always more patterns than expected.
Map fields explicitly and record what has no destination
A written mapping from every source field to its destination, and a list of what does not fit. The list is the deliverable that prevents quiet content loss, because it forces a decision instead of permitting an omission.
Migrate in passes, not one run
Bulk content first, then media, then the structures that depend on both. Each pass is verified before the next begins, so a mapping error is found when it affects one content type rather than the whole estate.
Verify by counting and by looking
Per-type counts against the source for completeness, and inspection for the structures where counts prove nothing — a correct number of pages with wrong content is still a failed migration.
Activate redirects with the cutover, never after
The window between the new site serving and the redirects existing is when search visibility is lost, and it is lost silently. This is a sequencing rule, not a preference.
Measure the result against a baseline
Crawl, indexation and impressions tracked against what the site had before, for weeks after the move. The report describes the trajectory rather than asserting success, because a platform move is not something whose outcome can be promised in advance.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Design
- Content model for WordPress, with each existing type mapped to a destination
- Field mapping, and an explicit list of content with no destination
- URL inventory across every pattern the site has used
- Redirect strategy by URL class
- Editing experience design, agreed with the people who will publish
Migration
- Content extracted from all sources, including bespoke databases and files
- Migration in verified passes: content, media, then dependent structures
- Media moved with every in-content reference rewritten
- Templates and editing experience built for the new model
- Verification by count per content type, plus inspection
Cutover and after
- Redirects activated with the cutover
- Sitemaps regenerated from the new structure
- Rehearsal on real data with a tested return path
- Crawl, indexation and impression tracking against the baseline
- A written account of what was migrated, what was omitted and what recovered
Architecture and technology
The migration decisions, in order
- What each existing content type becomes in WordPress
- Which fields map, which convert, and which have nowhere to go
- What the URLs become, and how every existing address maps onto them
- How media is stored and how references to it are rewritten
- Who can publish what, and whether that is enforced
- What happens to content that is being deliberately left behind
Where a WordPress migration loses content
- A content type with no destination, migrated into a generic field
- Media moved without every in-content reference being rewritten
- Structures an earlier migration left behind, never enumerated
- Content authored in a bespoke system that no export tool reads
- Taxonomies flattened because mapping them looked like a detail
- URL patterns nobody remembered, so no redirect exists for them
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The move is between servers, not platforms
The same software on new infrastructure — the same-platform transfer this page is not.
Server migrationSearch visibility is the main risk
The general migration discipline, including redirects and indexation recovery.
Website migrationsYou want WordPress to stay as the CMS
Keeping WordPress for editors while the front end is decoupled.
Headless WordPress developmentThe site needs building or extending afterwards
Custom WordPress engineering: themes, plugins and integrations.
WordPress developmentFrequently asked
How is this different from moving to a new host?
A host move keeps the software the same and changes where it runs; for a WordPress site that is a server migration and the risks are transfer, downtime and DNS. This changes what the content lives in, so the risks are the content model, the URL structure and what happens to content that does not fit. If your site is already on WordPress and you are changing hosting, you want the server migration page. If the platform is changing, the content model is the first decision to make and it determines most of the rest.
Will we lose our search rankings?
A migration that inventories every URL, maps it by class and activates redirects with the cutover usually holds a site's visibility, and no responsible provider promises an outcome for a platform change. Rankings fluctuate for reasons that are partly the migration and partly everything else, and the honest commitment is to the mechanics: complete inventory, reviewed redirects, correctness in status codes and canonicals, and measurement against a pre-migration baseline. What reliably loses visibility is a partial redirect map or a gap between the new site serving and the redirects existing.
Can we keep publishing during the migration?
Yes, and it is how the work is planned. Bulk content and media move in advance, so the cutover window covers only what changed in the meantime. A migration that freezes publishing for weeks costs more in editorial output than most of the technical risks it avoids, and the staged approach exists specifically to avoid having to choose.
What happens to content that does not fit the new model?
It is found during field mapping and decided then. That may mean a new field, a conversion into an appropriate structure, or a deliberate decision to leave it behind — and the third is a legitimate answer as long as it is a decision. What is not acceptable is arriving in a generic field, or being omitted silently, which is how migrations lose content and only find out months later when someone looks for a page that is no longer there.
Do you rebuild the design at the same time?
The templates have to be built for the new content model, so the structure is inevitable; a full redesign is a separate decision. Doing both at once is often right, and it does mean two changes are being judged together, which makes attributing a search outcome harder. Where the design is being changed as well, we will say so explicitly in the plan so the measurement afterwards is interpreted correctly rather than misread as a migration result.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.