Content and authors
Articles, basic pages and other agreed content types, with their titles, text, publishing state and author references. Custom fields need an explicit destination.
Moving away from Drupal, or moving into it?
Leaving Drupal: choose the destination for each content type before exporting. A staff directory needs fields and relationships that an ordinary article may not have. See Drupal to WordPress for that route.
Moving into Drupal: prepare the bundles, fields and vocabularies that will receive the records. Start with WordPress to Drupal if that is your source. Upgrading an existing Drupal installation is a separate scope from transferring its content to another CMS.
Available migration objects and capabilities depend on the selected source and target systems. Check current integration status before using this planning guide.
Content types, references and public paths
Assess migrations from Drupal and into a prepared Drupal site. The starting point is your Drupal version, content types and enabled modules. Source access may use JSON:API where available or a version-compatible Bridge; the destination connection is checked separately.
Categories and navigation
Vocabulary terms, their hierarchy, content assignments and supported menus. A menu link must point to the new record, even when its URL changes.
Files and references
Image and document availability, inline links and relationships between records. Private files need an agreed access method.
Public addresses
Current aliases and any available redirect history. Use the actual public URLs to prepare the destination routes.
What happens to Views, Paragraphs and layouts?
Views, Layout Builder sections, theme templates and module behavior need their own implementation on the destination. Paragraphs, revision history, moderation and translations are reviewed individually. Do not assume that a node export contains everything those features need.
Keep the content types that editors actually use
Consider a Drupal “Staff profile” with a job title, portrait and department reference. Turning it into a plain WordPress page would keep the visible text, but could leave your team maintaining the department directory by hand.
A better mapping might use a prepared staff post type, a job-title field and a department taxonomy. That is an illustrative design choice, not an automatic conversion: the destination fields and templates must exist, and the migration needs permission to write them. The Drupal to WordPress guide covers the field-by-field decisions.
Check a staff profile beyond the node count
Take a profile that refers to a department and a private document. After the trial, open the department directory and follow its link to the profile. Confirm that the title and portrait appear, the department reference resolves, and an anonymous visitor cannot retrieve the private document.
Then edit the profile in the destination. If the department exists only as text pasted into the body, the relationship has been lost even though the page looks right. Record that as a mapping issue in the validation report. If the destination cannot preserve the file restriction, hold the affected content until access is implemented.
Moving into Drupal
The destination needs its content types, fields, languages and permissions before migration starts. An incoming category might become a term in an existing vocabulary; a product feature list might need several fields. Those decisions belong in the mapping, alongside who will build the corresponding display.
For a WordPress source, begin with WordPress to Drupal. A Drupal version upgrade is a separate assessment: we need to know which configuration, contributed modules and historical data the project expects to retain.
What to send for an estimate
Send the site URL, Drupal version, intended destination and a rough count by content type. Add the names of modules that own essential content, such as directories or document libraries. Screenshots of field settings can help explain the model; credentials are not needed in the enquiry.
A small site with heavily nested records can need more mapping work than a large article archive. See the cost factors and timeline dependencies before choosing a package.
The Drupal trial and final transfer
- 1. Inspect a sample: Confirm the connection can read the fields and files the project needs.
- 2. Agree the mapping: Assign each content type, field and relationship to its destination.
- 3. Review the trial: Check complete records in the new site, including navigation and restricted content.
- 4. Plan the final run: Agree the publishing freeze or delta work, URL changes and acceptance checks.
Technical references
Scope is reviewed against the source and destination documentation available for the project.