02 / Our method

A considered route.
A checkable result.

Five connected stages. Clear outputs. Review points that make the migration understandable to technical teams, editors and project owners.

The delivery route

Each stage answers a different question.

01

Discover & define

Establish the source version, available access and export routes. Inventory content types, assets, languages, URLs and integrations. Agree the inclusion rules, responsibilities and acceptance criteria.Output: Source baseline, scope & dependency register

02

Map the destination

Define WordPress content types, fields, taxonomies and relationships. Decide how templates and editorial workflows will work. Record transformation rules and URL decisions.Output: Content model, mapping & destination architecture

03

Prove a representative pilot

Test content that exposes the real complexity: connected records, embedded media, unusual fields, languages and edge cases. Review the result with the people who will publish it.Output: Pilot import, issue list & agreed adjustments

04

Transfer & reconcile

Run controlled imports using source identifiers. Compare the agreed source and target inventories, check relationships and media, and record exclusions and unresolved exceptions.Output: Import report, reconciliation & exception decisions

05

Test, release & hand over

Review templates, links, redirects, forms, integrations and editing workflows. Coordinate the last content changes, a backup and rollback plan. Check the production site after launch.Output: Release checklist, post-launch checks & handover

Reconciliation & QA

“Imported” is a starting point.

Check the records

Compare the included source inventory with the target. Counts help detect gaps; source identifiers and field checks help explain them. Document deliberate exclusions rather than hiding them in a total.

Check the connections

Review relationships, media references, language variants and internal links. A complete record can still point to the wrong file or the wrong version.

Check the experience

Test representative templates, navigation, search, forms and editing tasks. Include mobile layouts and accessibility checks in the acceptance plan.

Check the release

Coordinate source changes, redirects, indexing rules and external services. Keep a backup and rollback procedure, and agree who makes the final release decision.

Practical preparation

Make room for the final content change.

Content can change while the destination is being built. The release plan therefore needs a clear way to handle the gap: a content freeze, a final export and import, or another agreed update approach.

We also identify what happens to the source after launch — access, retention and any remaining dependencies are deliberate decisions.

Bring these to the first conversation

  • Current site URL and source access constraints
  • An overview of content types and languages
  • Known forms, APIs and external services
  • Your release window and decision makers

Start with a conversation

A better migration starts
with a better brief.

Bring us the site you have and the challenges you want to leave behind. We’ll start with the right questions.

Let’s map your move