Drupal Migrations Start With Content Types, Taxonomies and Views

Drupal is often chosen by organisations with complex content: departments, publications, events, people directories and more. Over time, a Drupal site accumulates structure that is easy to underestimate. A clear plan begins by documenting how that structure is defined and how pages are assembled from it.

Entities and bundles in plain language

In Drupal, most content is stored as entities. Nodes are the familiar pages and articles, and each node belongs to a content type such as Basic page, Event or Staff profile. Taxonomy terms belong to vocabularies, users are entities too, and media items represent images, documents and video. Each content type or vocabulary carries its own set of fields.

Inventory the model

Record the following for each content type and vocabulary:

• Machine name and human label.
• Every field, its type, whether it allows multiple values and whether it is required.
• Entity reference fields and what they point to.
• How many published items exist and when the most recent was updated.
• The URL alias pattern, often defined with a path automation module.

The counts are important. A content type with four items from many years ago may not deserve a full rebuild.

Views are where pages come from

Many Drupal pages are not single nodes but views: lists, grids, calendars or directories built by querying content. A views inventory should capture the path, the filters, the sort order, any exposed filters visitors can use and the display format. Without this, a migration can carry over every article and still lose the pages that organised them.

Blocks, menus and layout

Record custom blocks, block placement by region, and any layout configuration. Menus deserve their own export because their hierarchy often reflects how visitors navigate. Paragraph-style components used for flexible page building should be listed with their fields, much like content types.

Modules and custom code

List enabled contributed and custom modules, then describe what each one does in business terms. Some provide editor conveniences that will not be needed later. Others implement rules such as access restrictions, form handling or integrations with external systems. Custom modules deserve a careful read, since their behavior is usually documented nowhere else.

Users, roles and permissions

If the site has authenticated visitors, such as members or staff, document roles and what each can see or do. Decide early whether those accounts move, whether a separate identity service is used, or whether that part of the site becomes a different application.

Translations and revisions

Multilingual Drupal sites store translations alongside the original. Plan how languages map to URLs on the new site. Revisions are useful history, but most migrations move only current content and archive the rest. Confirm that choice with the people responsible for records.

A sensible order of work

1. Export the content model and counts.
2. Inventory views, menus and blocks.
3. Review modules and custom code for business rules.
4. Build a URL inventory including aliases and redirects.
5. Prototype the new content model with a representative sample.
6. Run trial imports and compare page by page.

What a good plan delivers

A documented Drupal model lets a migration keep the structure your team invested in while removing complexity no one uses. It also gives everyone involved a shared vocabulary, which makes estimates, testing and sign-off far more reliable.