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

Seneste artikler

Få en ugentlig marketingrapport fra GA4 og Google Ads med kontrollerede beregninger, tydelige dataforbehold og et kort AI-udkast, der hjælper jer på mandagsmødet.

Brug AI til webshoppens alt-tekster med en overskuelig pilot: kortlæg billederne, få danske forslag, og kontrollér resultatet i WordPress og WooCommerce.

AI-baseret ticketanalyse kan afsløre gentagne klager, produktfejl og huller i dokumentationen – uden at virksomheden behøver endnu en chatbot.

OpenSSH 10 fjerner DSA og advarer om nøgleudveksling, der ikke er post-kvantesikker. Her får du en metode til at afgrænse SFTP-oprydningen uden at svække alle SSH-forbindelser.

Botforespørgsler overstiger nu menneskelig webtrafik. Lær at auditere AI-crawlere, fastsætte regler på stiniveau, håndhæve robots.txt og måle det forretningsmæssige afkast.

Cloudflares Tunnel-opdateringer fra 2026 forbedrer kortlægning, overvågning af replikaer, logstreaming og overdragelse – men synliggør samtidig svagt ejerskab og mangelfuld praksis for failover og logging.

Sådan bruger du AI til mødenoter og opfølgning, mens faste regler beskytter CRM-data, kundematch og pipeline mod fejl og forhastede ændringer.

Drupal 10 når end of life den 9. december 2026. Brug denne praktiske kortlægning til at afgrænse arbejdet med Drupal 11-parathed, Composer-efterslæb, moduler og custom code.

Apache 2.4.67 tydeliggjorde risikoen ved overtagne reverse proxies. Læs, hvordan du opgraderer til 2.4.68, gennemgår HTTP/2, AJP og .htaccess og tester ændringerne sikkert.

WooCommerce-blokke er standarden, men ikke alle webshops er klar. Brug denne praktiske gennemgang, testplan og rollback-procedure til at beskytte omsætningen i checkout.

Anmeld Greg på Google

Greg Nowak Google-anmeldelser

 

Skriftlige anbefalinger fra Trafik og Veje, Aarhus Kommune (2011) og AgroTech (2010) — læs dem på LinkedIn.