Importing External Data into Drupal: A Practical Migration Plan

Illustrated infographic summarizing: 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.

Related on GrN.dk

Need help with this kind of work?

Plan your Drupal migration with Greg Get in touch with Greg.

Sources

Latest articles

An internal AI assistant can cite an obsolete handbook with confidence. Here is how to manage document ownership, updates, deletions, access and answer review.

Cloudflare Free provides useful website protection, but its rate limiting and bot controls have limits. Here is how to assess them for a WordPress site.

An AI assistant can answer questions and guide customers to a booking. Here are practical boundaries for prices, delivery times, personal data, and contact with a staff member.

Google and Bing now offer first-party AI search visibility reports. Here’s how to build a useful baseline without inventing a misleading GEO score.

AI crawlers can copy a familiar name. Here’s how to verify signed agents at the edge while keeping legitimate automated traffic moving.

A critical Webform release is a reminder to audit every Drupal codebase, configuration and deployment—not just the main production website.

A secure AI workflow can turn Meet and Teams transcripts into approved decisions and tasks in Jira or Asana—without giving up control.

NGINX 1.31.5 can route on JSON body values. Here’s how to weigh the performance, security, and operational trade-offs before using it.

OpenAI can keep agent sessions running, but reliable workflows still depend on clear failure states, safe retries, validation, limits and human fallback.

AI can identify termination deadlines and price adjustments in supplier contracts, route uncertain findings for approval and create the right reminders.