Drupal content migration tool: what we use in 2026

Search for a Drupal content migration tool and you get twenty module pages, a decade of forum threads, and a few videos promising a migration in thirty minutes with no code. All of it is technically correct and none of it tells you which tool to actually reach for. The answer depends on what you’re moving and where it’s going, and after enough of these we’ve settled on a short default list. Here’s what we use in 2026 and when we switch off it.

The default: core Migrate API

For almost any real migration into a current Drupal site, we start with the Migrate API that ships in core, paired with two contrib modules: Migrate Tools and Migrate Plus. Migrate Tools gives you the Drush commands to run and roll back migrations. Migrate Plus adds the config-driven migration format so you define the job in YAML instead of writing a module for every source.

Why this is the default and not a paid tool: it’s re-runnable. You can run a migration, check the result, roll it back, fix the mapping, and run it again until it’s right. That single property matters more than anything a one-click importer offers, because no migration is right on the first pass. You always find a field that mapped wrong, a date format that didn’t parse, a taxonomy term that split in two. With the Migrate API you fix and re-run. With a black-box tool you cross your fingers.

It also handles the upgrade path directly. The migrate_drupal module, also in core, knows how to read an old Drupal database and pull its content and configuration forward. That’s the engine behind every Drupal-to-Drupal move, and it’s free.

When core Migrate is the wrong tool

Reaching for the Migrate API to copy a site from staging to production is like renting a moving truck to carry a chair. Two other tools cover the jobs the Migrate API is overkill for.

Backup and Migrate is what we use to clone a whole site at the same Drupal version — dev to staging, staging to production, or pulling a live site down to a laptop. It moves the database and files wholesale. It is not a content-mapping tool and it will not move you between major versions, but for “make this environment look like that one” it’s the fastest thing there is.

The Default Content and Single Content Sync modules handle the narrow job of moving specific nodes between two sites of the same version — a set of landing pages built on a dev site that need to land on production without dragging the whole database along. They export chosen content to files you commit to your repo and import on the other side. Handy for a content team that builds in one place and deploys to another.

The 2026 reality: Drupal 7 is finally done

The migration landscape looks different now that Drupal 7 reached end of life in January 2025. For years the dominant migration job was hauling a crusty Drupal 7 site into Drupal 9 or 10. Those jobs still land on our desk, but they’re the exception now, not the rule. Most migrations in 2026 are Drupal 9 to 10, or 10 to 11 — and those are gentler, because the data model didn’t change the way it did in the leap out of Drupal 7.

If you are still on Drupal 7, the honest advice is that you’re not doing a content migration, you’re doing a rebuild with a content migration bolted onto it. The theme layer, the modules, and half the contrib ecosystem you relied on don’t exist in the same form anymore. Treat it as a new build that happens to inherit your old content, budget accordingly, and don’t let anyone sell you a thirty-minute automated move for a site with real structure.

A word on the AI migration modules

There’s a newer class of module — AI Migration and AI Content Migrate among them — that uses a language model to read a web page and generate a Drupal migration against your content type schema. The demos are impressive. We’ve tried them, and here’s the honest read: they’re genuinely useful for pulling unstructured content into Drupal, like scraping an old brochure site with no database you can reach. They are not something we trust with structured data.

If you have a real Drupal database with clean field mappings, a language model guessing at those mappings is a step backwards from the Migrate API that can read the schema directly and deterministically. Use the AI tools where the alternative is copy-paste by hand. Don’t use them where a proper source connection exists. Anything a model infers, you have to verify by hand anyway, and verifying a thousand guessed mappings is slower than writing the correct one once.

What breaks, every time

The tool is rarely the hard part. The predictable failure points are the same across every job:

• Media and files. Getting the actual image and document files moved, and re-pointing every reference at the new file entities, is fiddlier than the nodes themselves.
• URL aliases and redirects. Old paths that don’t redirect to new ones cost you every search ranking the old site earned. Map them before you cut over, not after the traffic drops.
• Users and permissions. Password hashes, roles, and the content-to-author links all need deliberate handling, and it’s easy to orphan content from its author.
• Field formats and text filters. A body field that rendered fine under one text format can come across as raw markup if the format doesn’t exist on the target.

The redirect one is the expensive mistake. A site with years of earned rankings can lose a big share of its traffic the week after a migration, purely because nobody built the map from every old URL to its new home. That map is boring work and it’s the single highest-value hour in the whole project.

Our take

Default to the core Migrate API with Migrate Tools and Migrate Plus, because re-runnable beats fast. Use Backup and Migrate to clone same-version environments. Treat the AI migration modules as a content-entry helper for unstructured sources, not as a migration engine for a database you can already read. And spend real time on the redirect map, because that’s the part that shows up in your analytics whether you planned for it or not.

If you’d rather hand the whole thing off, Drupal migrations are part of what we do — we run Drupal in production and handle migrations and version upgrades end to end. If it’s specifically a version jump you’re staring down, we wrote up the Drupal 9 to 10 upgrade and the module traps that stall it. Send us the source site and the target version and we’ll tell you whether it’s a migration or a rebuild wearing a migration’s clothes.

If the answer looks like a rebuild, it’s worth stepping back and asking whether you rebuild on Drupal at all. We laid out the running costs of both platforms in our Drupal and WordPress comparison, written from the maintenance side rather than the sales side.