Move to WordPress with your content accounted for.
WebXd plans and executes CMS migrations to WordPress around the information your site already holds. From Drupal, AEM, or Sitecore, the work covers content mapping, URL decisions, media, publishing responsibilities, and a tested cutover. Your team can review what will move and how it will work before the live site changes.
Count the information behind the pages.
A page count is a useful starting point, but it leaves important work hidden. A resource page might depend on a topic, an author, a download, and a shared contact record. We inventory those relationships alongside the visible pages, then record whether each item will move, merge, remain elsewhere, or be retired.
The ledger gives your content owners a place to make decisions. It also records items that need attention, such as an outdated attachment or a page with no responsible department. A migration should make these exceptions visible early enough for someone to resolve them.
| Inventory | What to account for |
|---|---|
| Content and fields | Types, relationships, languages, publication state |
| Routes and discovery | Public URLs, aliases, links, metadata, redirects |
| Files and embeds | Images, PDFs, descriptions, external dependencies |
| People and permissions | Bylines, accounts, approval and publishing roles |
Keep the meaning of each field.
In our fictional Northline library, “Watershed field guide” is more than a title and a body. It has a topic reference, a reviewed date, a PDF, and an approval owner. The mapping specifies a WordPress destination for each value and keeps the source identifier so reviewers can trace the imported record.
An importer can move values correctly while leaving authors with an awkward editing screen. We test the destination by asking an editor to replace the PDF and update its review date. That task reveals whether the information is stored in useful fields and whether the person has the right permissions.
| Source field | Before | WordPress destination |
|---|---|---|
| Source ID | R-014 | Retained migration reference |
| Title | Watershed field guide | Resource title |
| Topic reference | Water stewardship | Resource topic taxonomy |
| Reviewed date | 2026-09-18 | Reviewed date field |
| PDF reference | field-guide.pdf | Download linked to imported media |
| Approval owner | Learning team | Named reviewer and publishing role |
Drupal to WordPress
Drupal content can use types, fields, taxonomy, and references. We inspect the source definitions and map the relationships as well as the text. Repeated components, translated records, and custom modules need explicit treatment in the destination rather than assumptions based on the appearance of a page.
AEM to WordPress
AEM Content Fragments hold structured content independently of page layout. We identify fragments, variations, references, and page components separately. The migration scope then names what will become WordPress content and what needs a new presentation or integration, based on your AEM version and available export access.
Sitecore to WordPress
Sitecore items follow templates, and fields may receive inherited standard values. We inspect effective values and relationships before choosing a destination. Content transfer, rendering behavior, personalization, and connected systems each need an agreed treatment; moving the item text does not settle all four.
An old link needs a deliberate destination.
We assemble the URL inventory from the source CMS, a crawl, sitemaps, and available search or analytics records. These sources reveal different parts of the site. An orphaned PDF or a campaign landing page can still receive visitors even when it is missing from the main navigation.
Where a route can stay useful, retaining it may be the clearest choice. When it changes, the route map identifies the relevant replacement and a direct permanent redirect. If content is removed without a suitable replacement, its route should return a proper error response. Sending every retired page to the homepage obscures the decision.
The checks follow the route through to its final page. We review response codes, redirect chains, internal links, canonical URLs, and indexability. Search visibility can fluctuate during a move, so the migration plan includes monitoring and a defined response to problems rather than a promise of unchanged rankings.
| Old route | Destination | Disposition |
|---|---|---|
| /resources/field-guide | /resources/field-guide | Keep · 200 |
| /learning/watershed-guide | /resources/field-guide | Direct redirect · 301 |
| /events/retired-workshop | No equivalent content | Retire · 410 |
A copied page can still point to a missing file.
Media needs its own inventory. We track the original file, its destination, and the records that use it. Checks cover downloadable documents, embedded images, alternative text, captions, and links inside the content. The source file remaining temporarily online should not disguise a missing copy in WordPress.
Some dependencies belong outside the media library. A video provider, an application form, or a document repository may remain in place. We record who owns that connection and test it in the new page. Files needing content or accessibility remediation are identified as separate work so the transfer does not imply they have been corrected.
- Confirm the destination file opens
- Check links after the source is unavailable
- Review descriptions and document titles
- Identify the owner of each external embed
Rehearse the move while decisions can still change.
Your content owners decide whether information is accurate and should remain public. We translate those decisions into migration rules and bring exceptions back for review. The plan names the person who can approve content, the person who can publish it, and the person who can authorize the cutover.
A rehearsal uses representative records with the difficult cases included. We compare source and destination counts by content type, inspect relationships, and review pages with editors. An exception log records missing values, rejected files, and unexpected formatting. The team agrees which issues block launch and which can enter a later, assigned work list.
The rehearsal also tests repeat imports. If a content owner fixes the source, the next run needs to update the intended record rather than create a duplicate. We establish how changes will be captured between rehearsal and cutover, including a publishing freeze or an agreed final update import.
| Responsibility | Decision or action |
|---|---|
| Content owner | Approve keep, merge, retire, and accuracy decisions |
| Migration team | Apply mappings, reconcile imports, resolve technical exceptions |
| Publishing owner | Test editing tasks and approve destination permissions |
| Launch owner | Accept evidence and authorize the cutover window |
Check the destination after the switch.
Staging approval is one part of release readiness. The cutover plan also identifies the current backup, the final content change boundary, hosting responsibilities, and the conditions for reversing the switch. A rollback needs to account for any new submissions or edits made after launch.
Once WordPress is live, we repeat the checks that depend on production. Priority routes should reach their expected pages, files should open, and important forms should deliver to their intended systems. We review crawl access, canonical tags, sitemaps, and measurement collection against the agreed release scope.
The handover includes the mapping rules, route inventory, import results, unresolved exceptions, and a named owner for follow-up. The proposal defines the verification window and what happens when an issue is reported. Your team should be able to explain what moved and find the evidence for that answer.
Evidence for the release decision
- Content reconciled against the approved inventory
- Changed routes reach the intended final destination
- Files, forms, and integrations checked on production
- Public pages have the agreed crawl and indexing settings
- Editors can complete the agreed publishing tasks
- Follow-up issues have an owner and a response path
Set the boundaries before estimating the move.
Does migration include a redesign or new WordPress build?
Those can be part of the engagement, but they need their own scope. Migration covers extraction, mapping, transfer, and verification of the agreed content and routes. A new theme, redesigned layouts, custom blocks, or replacement functionality adds design and development work. We define the destination before estimating how to move into it.
Can our team keep publishing during the project?
Usually the plan can accommodate ongoing changes before cutover. The important decision is how those changes reach WordPress. We agree on a freeze period or a final update import, assign responsibility for late edits, and test that method during rehearsal. The practical choice depends on source access and the kinds of records that change.
Will accounts, revisions, translations, and integrations transfer?
We list each of these explicitly in the inventory. Public bylines and login permissions require different decisions, and historical revisions may need an archive instead of a direct import. Translations, forms, memberships, and integrations can add substantial work. A sample export and a review of the destination help establish what is feasible.
What determines cost and timing?
The estimate depends on content types, relationships, file volume, export quality, destination readiness, and review availability. A large collection of consistent records can be simpler than a smaller site with many custom components. Share the current CMS, a representative content sample, and your launch constraints so we can define the work and milestones.