victorstackAI

Posted on Mar 15 • Originally published at victorstack-ai.github.io

Review: Drupal 12 Removing Migrate Drupal and Migrate Drupal UI from Core, with a Migration-Readiness Plan for Drupal 10/11 T...

#review #drupal #wordpress #migration

Drupal core is drawing a clean boundary for Drupal 12: the general Migrate API stays, but the Drupal 6/7 source migration path shipped as migrate_drupal and the old browser workflow shipped as migrate_drupal_ui are being removed from core.

That is not just housekeeping. It changes how Drupal 10 and Drupal 11 teams should structure their modernization programs right now, especially agencies and platform teams still treating "upgrade to the next major" and "migrate from an old site" as one blended workflow.

What changed, exactly

Two separate deprecations now define the path to Drupal 12:

November 14, 2025: Drupal core deprecated Migrate Drupal UI in Drupal 11.3.0 and marked it for removal in Drupal 12.
January 12, 2026: Drupal core deprecated Migrate Drupal in Drupal 11.4.0 and marked it for removal in Drupal 12.

The important detail is what remains in core. Drupal 12 is still expected to contain the migration framework itself: migrate, migrate_plus-style patterns in contrib, custom process plugins, destination plugins, and general ETL-style migration architecture still matter. What is going away is the core-maintained path for migrating Drupal 6/7 sites into modern Drupal.

So if your team heard "Drupal 12 is removing migration from core," that is too broad and operationally misleading.

Why Drupal core is doing this

The rationale is straightforward: Drupal 7 reached end of life in January 2025, and the old in-core migration path existed primarily to help teams move legacy Drupal data into current Drupal builds. Once that legacy bridge stops being a core responsibility, it becomes easier for core to reduce maintenance burden and keep its upgrade story focused on supported major versions.

That is a reasonable product boundary. It is also a forcing function:

Drupal 10/11 to Drupal 12 upgrades should be treated as a standard major-version upgrade lane.
Drupal 6/7 to modern Drupal migrations should be treated as a separate legacy modernization lane.

Teams that keep mixing those lanes will feel more pain than teams that separate them now.

Who is actually exposed

This removal matters most to four groups:

Agencies with long-tail Drupal 7 client portfolios
If your operating model still assumes you can keep using core-led migration workflows until the last possible moment, Drupal 12 breaks that assumption.
Enterprise platform teams with deferred replatforming
If the plan was "get onto Drupal 11 first, then migrate remaining legacy estates later," you now need to check whether that later phase silently depends on modules that disappear in Drupal 12.
Teams whose runbooks depend on the browser UI
If operational staff rely on migrate_drupal_ui instead of scripted or CI-friendly migration execution, this is a workflow risk, not just a package change.
Mixed Drupal and WordPress shops
WordPress is relevant here because many agencies standardize modernization playbooks across both CMS stacks. This Drupal change is a reminder that legacy import bridges are not permanent platform guarantees.

What this does not mean

Several bad conclusions are easy to make here. Avoid them:

It does not mean Drupal 12 has no migration system.
It does not mean custom migrations are obsolete.
It does not mean contrib cannot continue legacy-source migration support outside core.
It does not mean Drupal 10/11 teams should panic-upgrade migration programs without sequencing.

The right reading is narrower: core is retiring responsibility for the old Drupal-to-Drupal source upgrade lane.

The migration-readiness plan for Drupal 10/11 teams

If a team still relies on core-led upgrade workflows, this is the plan I would standardize now.

1. Inventory actual dependency, not assumed dependency

Do not ask "Do we use migrations?" Ask:

Do any sites still depend on migrate_drupal?
Do any runbooks still depend on migrate_drupal_ui?
Do any deployment docs, internal scripts, or support playbooks assume browser-driven upgrade imports?
Do any custom modules extend Drupal-source migration plugins that come from the deprecated modules?

At minimum, scan:

Composer manifests and lock files
Site install profiles or recipes
Custom modules for Drupal-source plugin references
Internal documentation and onboarding guides

If you do not do this inventory, you will underestimate exposure because the risky dependency is often procedural, not just technical.

2. Pull legacy migrations forward onto Drupal 11, not Drupal 12

If you still have real Drupal 7 migration work left, the safe assumption is this: complete or at least initiate that work on Drupal 11 while the deprecated path still exists.

That does not mean rushing production launches. It means freezing the target platform choice for those migration programs now instead of pretending Drupal 12 will preserve the same in-core path.

For many teams, the least risky sequence is:

Land the legacy-site migration onto a supported Drupal 11 codebase.
Stabilize content, config, and editorial workflows.
Then treat Drupal 11 to Drupal 12 as a separate major upgrade.

That sequence is slower politically, but safer technically.

3. Remove operational dependence on the UI

migrate_drupal_ui disappearing should push teams toward scripted, reviewable, repeatable migration execution.

If staff currently depend on clicking through a browser-based migration flow, move that knowledge into:

Drush-driven commands
CI jobs
Versioned migration configuration
Environment-specific secrets and source connection handling
Documented rollback and rerun procedures

This is the same maturity shift WordPress teams make when they stop relying on one-off wp-admin import routines and move critical content moves into code and repeatable scripts.

4. Preserve source-of-truth artifacts now

Before teams get further into Drupal 12 planning, preserve the migration inputs that matter:

Source database snapshots
Files directories and asset inventories
Migration mapping state where applicable
Field and content model documentation
Business rules that were only ever captured in migration notes

Too many migrations fail on the second pass because the source data and transformation assumptions were treated as disposable project scaffolding.

5. Separate upgrade governance from migration governance

This is the biggest process fix.

A Drupal 10/11 to 12 upgrade board should track:

Deprecated API removal
Core/contrib compatibility
test coverage
composer constraints
hosting/runtime readiness

A legacy migration board should track:

source-system access
field mapping completeness
editorial acceptance
delta reruns
cutover sequencing

If one board owns both, migration work will keep being deprioritized until the deprecated bridge disappears.

6. Test custom migration logic against the post-removal future

Even if you do not need Drupal 7 imports anymore, some teams still have custom migration code tightly coupled to assumptions from the legacy core modules.

Review custom code for:

Source plugins tied to Drupal legacy schemas
Process plugins that assume old map behavior
Operational steps that require UI-led execution
Documentation that treats migration as a one-time installer action rather than maintainable code

The goal is simple: your custom migration layer should stand on the general migration framework, not on disappearing core convenience modules.

7. Decide your cutoff date explicitly

Every Drupal platform team should now define one internal policy date:

After this date, no new modernization project may assume core-led Drupal 6/7 migration support on a Drupal 12 target.

Without an explicit cutoff, sales promises and internal roadmaps will keep smuggling obsolete assumptions back into delivery.

The practical recommendation

For most Drupal 10/11 teams, the best posture is:

Use Drupal 11 as the last planned landing zone for any remaining Drupal 7 migration programs that still benefit from core-led legacy-source support.
Use Drupal 12 planning to harden your major-upgrade path, not to postpone unresolved legacy migration work.
Move migration execution out of UI habits and into code, automation, and testable runbooks.

That is the real readiness plan. Not "wait and see whether contrib replaces it," and not "assume the old path still exists because the Migrate API still exists."

Why WordPress teams should care too

This is a Drupal-specific change, but the operating lesson travels well to WordPress:

Legacy importers are temporary bridges, not eternal platform guarantees.
UI-heavy migration workflows age badly.
The safest modernization programs separate content/data migration from platform-version upgrades.

Agencies running both Drupal and WordPress portfolios should treat this as another reason to keep migration logic versioned, scripted, and portable instead of hiding it in one product's convenience layer.

Bottom line

Drupal 12 is not killing migration. It is removing the core-owned Drupal legacy migration bridge.

Teams still depending on that bridge should make one move now: finish dependency discovery, shift remaining legacy migrations onto Drupal 11 plans, and redesign workflows so Drupal 12 upgrades are just upgrades, not unresolved legacy rescue missions.

Sources

Looking for an Architect who doesn't just write code, but builds the AI systems that multiply your team's output? View my enterprise CMS case studies at victorjimenezdev.github.io or connect with me on LinkedIn.

Originally published at VictorStack AI — Drupal & WordPress Reference

DEV Community