Importing External Data into Drupal: A Practical Migration Plan

By Greg Nowak. Last reviewed 25 July 2026.

Importing a forum, spreadsheet, legacy CMS, or operational database into Drupal is not simply a matter of matching columns. It is a controlled data project involving content design, business rules, privacy decisions, testing, and launch planning.

Drupal provides a capable migration framework, but the software cannot decide which historical records remain useful, whether former users should receive accounts, or how old URLs should behave. Those decisions need to be made before development starts. A good migration therefore begins with the future site—not the structure of the system being retired.

Define what success means

Start with a short inventory covering content, users, taxonomy, files, comments, redirects, languages, permissions, and important relationships. Then classify each group as migrate, transform, archive, or discard. This prevents obsolete structures and low-value data from being reproduced merely because they exist.

Agree acceptance criteria at the same time. Record counts are useful, but they are not enough. Success might also require preserved author attribution, working media, valid internal links, correctly assigned categories, searchable content, and redirects for valuable legacy URLs.

Question	Likely decision	What to verify
Will editors maintain this content?	Drupal content or custom entity	Fields, workflow, ownership
Is it needed only for reference?	Read-only archive	Access, search, retention
Do former users need to sign in?	User migration or attribution only	Consent, status, authentication
Must files and comments remain connected?	Separate dependent migrations	Stable IDs and lookup results
Does the source change after extraction?	Freeze window or incremental run	Cut-off time and delta handling

A migration decision matrix for turning business requirements into an implementable Drupal scope.

Choose a source that can be inspected

CSV remains a sensible option for finite, reasonably flat datasets. It can be reviewed by owners, editors, and developers, while Drupal's maintained Migrate Source CSV module provides a source plugin for the core Migrate API. Every row should have a stable, unique source ID; row numbers are a poor substitute if files may be regenerated.

A direct SQL source is often better for large datasets or complex relationships. JSON, XML, or an API may suit repeatable feeds. If data needs regular two-way synchronisation, however, the requirement has moved beyond a one-off migration and should be designed as an integration.

Keep an untouched source extract, document its encoding and delimiters, and identify personal or confidential fields before sharing it with a delivery team. Clean disposable test copies rather than silently changing the only source of record.

Build small, ordered migrations

Drupal's Migrate API follows an extract-transform-load model expressed as source, process, and destination. The process stage can normalise values, provide defaults, skip unsuitable rows, and resolve references. Migrate Plus can represent migrations as configuration entities and group related migrations; Migrate Tools supplies management commands and a useful dependency view.

Do not begin with one enormous migration. Establish the destination model first, then implement one entity type at a time. A common order is taxonomy and users, followed by files or media, primary content, comments, and redirects. Declare dependencies where later records require IDs created by earlier migrations.

Start with awkward but representative samples: missing authors, duplicate titles, embedded markup, unusual characters, orphaned files, and deep relationships. A tidy sample proves very little.

Rehearse the command-line workflow

With a current, compatible Migrate Tools installation, the core working loop remains straightforward:

drush migrate:status
drush migrate:import migration_id --limit=50
drush migrate:messages migration_id
drush migrate:rollback migration_id

Use the exact commands supported by the versions locked in the project's Composer files. Run imports in an isolated development or staging environment first. Drupal's documentation also recommends considering modules that perform expensive work when entities are saved; search indexing, outbound notifications, webhooks, and other downstream processing should be deliberately controlled during rehearsals.

A rollback is part of migration development, not a complete disaster-recovery strategy. Maintain verified backups and a documented restore procedure before any production run.

Test meaning, not just totals

For each rehearsal, capture imported, skipped, failed, and warning counts. Inspect migration messages and compare selected records side by side with the source. Test relationships in both directions: open a migrated article and check its author, media, taxonomy, comments, and links; then inspect samples belonging to each author or category.

Ask editors to review content quality and operations staff to check permissions, workflows, search, and integrations. Agencies should provide a concise exception log explaining what was excluded and why. This turns apparent gaps into traceable decisions.

The production runbook should name the source freeze time, backup owner, command order, validation checks, redirect activation, cache and index work, sign-off owner, and fallback point. After launch, keep the source export, mappings, migration configuration, logs, and approval notes together.

When outside help is useful

A Drupal consultant or digital project manager becomes valuable when the project spans legacy databases, editorial judgement, privacy, agency coordination, and a fixed launch window. The useful contribution is not merely writing YAML: it is helping stakeholders settle the decisions that make the YAML dependable.

If you are replacing an old CMS, consolidating forum content, or bringing operational records into Drupal, talk to Greg about shaping the migration into a testable project with a clear scope and launch path.