Move forward.
Don't start over.
A serious migration is not moving pages from one database to another. It is deciding what deserves to survive, what needs to change, and how the business keeps moving while the platform does.
LEGACY / REALITY
MODERN / DELIBERATE
Migration is a chance to remove the past without losing its value.
Years of content, taxonomy, media, redirects, permissions, forms, custom code and editorial habits are hiding inside the old platform. Some of it is essential. Some of it is accidental. Some of it should never be migrated.
Drupal's own migration guidance emphasizes source inventory, clean destination environments, mapping, staged migration and testing rather than treating an upgrade as a simple version change.
The expensive mistake is moving everything.
Migration projects go wrong when teams optimize for “data moved” instead of “business preserved.” The source system contains years of decisions — and years of clutter.
Content is migrated before it is understood.
Duplicate, obsolete and structurally inconsistent content becomes permanent debt in the new system.
Customizations are treated as features.
Some need rebuilding. Some can disappear. Some reveal business rules nobody documented.
SEO is treated as a redirect spreadsheet.
URLs, metadata, internal links and search equity need to be part of the migration architecture.
The cutover becomes the first real test.
That is too late. Rehearsals, validation and incremental approaches reduce the unknowns before launch.
Six decisions
before one big move.
The sequence matters. We establish what exists, what matters, what changes and how it will be proven before the migration becomes a production event.
Inventory the estate.
Content types, fields, taxonomy, media, users, workflows, modules, integrations, URLs, performance dependencies and the things nobody put in the architecture diagram.
Design what should survive.
Map old structures to the target model. Decide what gets consolidated, transformed, retired or rebuilt.
Run the migration before launch.
Build repeatable migrations, test representative data, expose edge cases and measure the result in a controlled environment.
Protect discovery and continuity.
URLs, redirects, metadata, media relationships, permissions, editorial workflows and critical integrations are validated as part of the move.
Choose the right transition.
Big-bang, incremental or hybrid patterns are selected based on content volume, change rate, integration complexity and operational risk.
Make the new platform boring.
Monitor, tune, resolve edge cases, document the architecture and transfer operational understanding to the team that owns the platform.
Not just content.
The operating model.
Enterprise migration is multidimensional. The destination must preserve the relationships that make the platform useful, not merely the records that make the database full.
ENTITIES / FIELDS / TAXONOMY
FILES / REFERENCES / ASSETS
Transform structures where the new architecture demands it; preserve relationships that users and systems depend on.
URLS / REDIRECTS / METADATA
ROLES / WORKFLOWS / PERMISSIONS
Validate the paths users and editors rely on — not only the rows in the migration log.
MODULES / FORMS / LOGIC
CRM / ERP / DAM / API
Identify which behavior should be rebuilt, replaced, retired or moved behind a cleaner integration boundary.
There is no universal
cutover.
Big bang.
Appropriate when the estate is manageable, the destination is well rehearsed and a controlled maintenance window is acceptable.
Incremental.
Useful when the existing platform must remain active while sections, content or capabilities move progressively into the new system.
Hybrid.
When legacy systems, APIs and regulated workflows cannot move together, isolate the boundaries and migrate the platform in controlled stages.
The details are where confidence comes from.
Real enterprise migrations demonstrate why content mapping, custom behavior, performance, integration and cutover strategy have to be engineered together.
A recent enterprise Drupal migration case involved 10,000+ pages, 500+ custom forms, external dashboards and separate databases — ultimately consolidating them into a unified Drupal architecture.
Drupal documents staged approaches where the source stays live while content is migrated into staging and production in controlled passes.
Drupal's preparation guidance explicitly recommends understanding the source modules, dependencies and destination prerequisites before execution.
The goal is a platform that is easier to operate, safer to change and structurally ready for what the business needs next.
Your migration is difficult for a reason.
Let's find it before launch.
Bring us the current platform, the target state and the part you are least confident about. We'll start there with architecture, evidence and a path to reduce the risk.
Talk to a Migration Architect →