Enterprise WordPress content migration, mapped before anything moves

Different scope, same project. The migrate to WordPress page covers the decision and the engagement: the business case for leaving a legacy platform, timelines, integrations and governance.

This page covers one workstream inside that programme, the part where content actually moves. Mapping, transformation, import, redirects and validation.

If you are still deciding whether to replatform, start there. If the decision is made and you are working out what happens to twelve thousand records, you are in the right place.

Three inputs: an inventory of what exists, the target architecture, and an editorial call on what is worth carrying. The mapping records one decision per legacy object type:

• Moves as is. The target model has an equivalent and the fields line up.
• Transforms. The content becomes a different type, or its fields are split, merged or re-typed to fit the new model.
• Deprecates. It is archived rather than migrated, usually because nothing has referenced it in years.

Deprecating is the decision teams postpone, and the one that most reduces the cost of everything after it. Migrating dead content means paying to move it, to validate it, and to maintain it.

It depends on the shape of the source, and we decide up front because reversing that choice halfway through is expensive.

Two broad routes. An off-the-shelf import tool handles the common shapes, XML, CSV and JSON, with visual field mapping and repeatable runs. A custom pipeline, PHP, SQL, or an ETL layer over the REST API, is what unusual schemas and multi-system sources need.

Most enterprise migrations use both: the tool for the bulk, custom logic for the parts that do not fit. We name the specific tooling in the migration plan rather than here, because the right answer changes with the source and with what your team will maintain afterwards.

Redirects follow the same logic. Kept inside WordPress they stay editable by your team, which editors prefer. Past tens of thousands of rules, server-level rules perform better and we move them there.

URL mapping happens before anything moves. Every indexed legacy URL is matched to a destination and classified: 301 for a permanent move, 302 only where the destination is genuinely temporary.

Once implemented, the map is crawled to confirm coverage and catch chains, where one redirect points at another. Individually harmless, collectively a crawl budget problem.

Through cutover we watch Search Console coverage rather than waiting on traffic reports. The same discipline, described from the search side, is on our enterprise SEO page.

Yes, and most teams have to.

Two options, chosen per project. Freeze legacy content updates for a defined window before cutover, which is simplest when the window is short. Or keep publishing and run delta imports, where the pipeline re-runs against everything created or edited since the previous load.

Delta imports are why we configure imports as repeatable jobs from day one. Retrofitting rerunnability into a one-shot script during launch week is how migrations slip.