Importing External Data into Drupal: A Practical Migration Plan

By Greg Nowak. Last updated 2026-06-22.

Moving content into Drupal is rarely just an import job. It is a small data project: understand the source, decide what the destination should look like, clean the records, run a test migration, and only then bring it near production. That is especially true when replacing an older forum, CMS, or business system where years of posts, users, files, taxonomy, and odd historical fields have accumulated.

The good news is that Drupal's migration tooling is built for this kind of work. The core Migrate API provides the framework, contributed source plugins can help with formats such as CSV, and a careful migration configuration can turn messy external data into Drupal nodes, users, media, taxonomy terms, or custom entities. The hard part is not pressing import; it is making sensible decisions before the first row is written.

Start with the business outcome, not the old tables

If the source is an SMF forum, a legacy database, an exported CSV file, or another CMS, resist the temptation to reproduce every table in Drupal. Start by asking what the new site actually needs. Should forum topics become articles, discussion nodes, or archived read-only content? Should old user accounts be active users, attributed authors, or anonymised names? Do attachments need to become media items, or is a static archive enough?

This step matters because Drupal migrations work best when the target model is clear. A migration can map source fields to destination fields, transform values, look up related entities, preserve old IDs for references, and skip bad records. It cannot decide whether a decade-old forum category still belongs in the information architecture.

Decision	Practical question	Typical Drupal target
Content type	What should this record become for editors and visitors?	Node type, custom entity, or archived page
Identity	Do old users need accounts, attribution, or anonymisation?	User entity, author field, or text field
Relationships	Which comments, files, categories, and references must survive?	Migration dependencies and lookup plugins
Data quality	Which rows are duplicate, broken, spammy, private, or obsolete?	Pre-cleaned source data and skip rules
Launch safety	Can the migration be repeated, rolled back, and audited?	Drush commands, staging runs, and logs

A useful import plan maps business decisions to Drupal migration design before implementation starts.

Export the source in a format you can inspect

For older systems, a direct database-to-Drupal migration is possible, but CSV is often the most transparent first step. It gives owners, editors, and developers something they can inspect together. You can export tables from the source database, flatten joins where appropriate, and document each column before migration configuration begins.

That does not mean every migration should be CSV-only. Large datasets, complex relationships, or regularly synced sources may be better served by a custom source plugin, database connection, JSON feed, or API integration. The consultant's job is to choose the simplest approach that remains repeatable and testable.

Use Drupal Migrate as the import framework

Drupal's Migrate API is the right foundation for structured imports because it separates the migration into source, process, and destination stages. The source reads external records. The process stage transforms values, sets defaults, cleans text, resolves references, and prepares fields. The destination writes to Drupal entities.

For a CSV-based project, the contributed Migrate Source CSV plugin is commonly used to read CSV files into the Migrate API. For real projects, this is usually paired with Migrate Plus and Migrate Tools, so migrations can be configured cleanly and run from the command line. A typical workflow is:

Export a small representative sample from the legacy system.
Create the destination content type, fields, vocabularies, and media model in Drupal.
Write one migration configuration for one content type or entity at a time.
Run the migration in a local or staging environment and inspect the imported content.
Adjust mappings, cleanup rules, and dependencies before scaling up.

Common Drush commands still make sense in modern Drupal migration work. Exact command availability depends on installed tooling, but in Migrate Tools projects you will often see commands such as:

drush migrate:status
drush migrate:import migration_id
drush migrate:rollback migration_id
drush migrate:messages migration_id

Those commands are useful because migrations should be rehearsed. If a mapping is wrong, roll it back, fix the configuration, and run it again. That is much safer than writing one-off SQL into a live Drupal database.

Keep migration work auditable

A good migration leaves a trail. Keep the source export, the mapping document, the migration YAML, and the test notes together. Record known exclusions, such as spam posts, orphaned attachments, disabled users, or content deliberately left in an archive. This is not paperwork for its own sake; it prevents launch-week arguments about whether missing data is a bug or a decision.

It is also important to test references, not just counts. If 20,000 posts import successfully but half the authors, comments, or files are wrong, the migration has not succeeded. Compare samples from the old system and the new Drupal site side by side. Check old URLs if redirects are part of the scope. Ask editors to review content that represents the awkward cases, not just the tidy ones.

When to bring in help

External data imports are a good fit for a digital project manager or Drupal consultant when the work crosses business rules, legacy systems, editorial judgement, and implementation. The technical import is only one part of the project. Someone also needs to coordinate decisions, document tradeoffs, protect the launch plan, and make sure the new Drupal structure is actually useful after the migration.

If you are planning to replace an old forum, consolidate content from another CMS, or import operational data into Drupal, Greg can help turn the migration from a risky data dump into a controlled project with a clear mapping, test process, and launch path.

Related on GrN.dk

Need help with this kind of work?

Plan a Drupal migration Get in touch with Greg.

Sources

Last modified

2026-06-22