Drupal 7 no longer receives security updates. Your site is vulnerable to attacks, and there is no direct upgrade path to Drupal 10 — only a full migration. We have completed 20+ such projects, ranging from 50 to 200,000 nodes. Our experience helps avoid common pitfalls and keep downtime to a minimum.
Migrate API speeds up content transfer by 3–5 times compared to manual export. But migration isn't just about content: custom modules and themes must be completely rewritten. Drupal 7 is procedural and lacks Composer; Drupal 10 is object-oriented on Symfony with YAML-based routing. The architectural differences force a full code refactor.
Migration from Drupal 7 to Drupal 10: Step-by-Step Instructions
Architectural Differences: Why This Is Not an Upgrade
Drupal 7 and Drupal 10 are architecturally different systems. D7 does not use Composer, OOP, or Symfony components. Content is migrated via Migrate API, while theme and module code is rewritten entirely. This is a full refactoring, not an update. For example, hook_menu in D7 becomes YAML routes, and procedural functions become services using Dependency Injection.
Migration Strategies: How to Choose
| Strategy | Description | Downtime | When to Use |
|---|---|---|---|
| Migrate API | Programmatic migration of content from D7 DB to D10. Can be run multiple times before switch. | Minutes | Most projects |
| Manual content migration | Export via Views, import via Migrate or manually. | Hours | Sites under 100 nodes |
| Big bang | Full stop of D7, configure D10, migrate all at once. | Days | Simple sites where downtime is acceptable |
Migrate API is the recommended option. It allows running migrations multiple times, adding only changed content. The difference in effort between Migrate API and manual migration is 3–5 times in favor of automation. Using Migrate API can reduce budget by 60-80%.
How does Migrate API work under the hood?
Migrate API uses source, process, and destination plugins for each entity. The source reads data from the D7 database, the process transforms fields, and the destination saves into D10. This allows reusing plugins and easily configuring mapping.How to Migrate Custom Modules?
Custom Drupal 7 modules must be completely rewritten for Drupal 10. For example, hook_menu is replaced by a YAML file mymodule.routing.yml, and procedural functions become classes with annotations. The complexity of rewriting depends on the module size. Often, the entire business logic needs refactoring. Request a site audit to assess the effort.
How We Conduct Migration: Step-by-Step
First, we perform a full audit of the current site. We access the D7 server and collect metrics: list of active modules, node types, DB size. Then we spin up a new server with Drupal 10 and install migration packages.
composer create-project drupal/recommended-project drupal10-site cd drupal10-site composer require drupal/migrate_plus drupal/migrate_tools drupal/migrate_upgrade drupal/migrate_source_csv drush en migrate migrate_plus migrate_tools migrate_upgrade -y Connect the D7 database as an additional database in settings.php:
$databases['migrate']['default'] = [ 'driver' => 'mysql', 'database' => 'drupal7_db', 'username' => 'db_user', 'password' => 'db_pass', 'host' => '127.0.0.1', 'port' => '3306', 'prefix' => '', ]; The command drush migrate:upgrade generates YAML configurations for users, taxonomy, content types, fields, nodes, files, blocks, and menus. Then migrations are run in dependency order: first roles, then content types, fields, taxonomy, users, files, nodes, menus, and blocks.
drush migrate:import upgrade_d7_user_role drush migrate:import upgrade_d7_node_type drush migrate:import upgrade_d7_field drush migrate:import upgrade_d7_field_instance drush migrate:import upgrade_d7_taxonomy_vocabulary drush migrate:import upgrade_d7_taxonomy_term drush migrate:import upgrade_d7_user drush migrate:import upgrade_d7_file drush migrate:import upgrade_d7_node_complete drush migrate:import upgrade_d7_menu drush migrate:import upgrade_d7_block Problem Areas and Their Solutions
- CCK/Field API: Field Collection in D7 is not migrated directly — the
migrate_field_collectionmodule is required. - Views: Views 3 (D7) are partially transferred. Complex views with relationships must be recreated manually.
- Media files: Files are copied via the
file_copyplugin, with the source path specified insource_base_path.
Contact us for a consultation — we will assess the complexity of your project and propose an optimal plan.
How to Minimize Downtime?
We use delta migration. A few days before the cutover, we run the initial full migration. On cutover day, we first put D7 into maintenance mode, then run incremental updates: drush migrate:import --all --update. After that, we switch DNS to D10 and disable maintenance mode. Full downtime is 15-30 minutes. Contact us to evaluate your project.
What’s Included in the Work?
- Full audit of the current D7 site (modules, themes, content, DB)
- Content migration via Migrate API with integrity guarantee
- Rewriting custom modules and themes to OOP/Symfony
- Configuration of SEO modules (metatag, redirect, pathauto)
- Test migration and acceptance testing
- Documentation of the new architecture, server and admin access
- Two weeks of post-migration support
Request a D7 site audit to get precise timelines and cost.
Timelines and Cost
| Site Type | Timeline |
|---|---|
| Simple (< 100 nodes, standard content types) | 2-3 weeks |
| Medium (500-5000 nodes, custom modules) | 4-8 weeks |
| Large (50k+ nodes, complex dependencies) | 3-6 months |
Cost is determined individually after an audit. Contact us to discuss the details.