Homepage

Moving from Drupal 6 or 7 to Drupal 11

Use this path when the platform is on a very old Drupal version and patching is no longer a responsible plan. For the client, this means building a new system without losing important content, business logic or visibility.

What this means for the client

  • the old platform is not simply switched off; its important content and workflows are moved in a controlled way;
  • technically this usually means building the system again, not simply upgrading the existing codebase;
  • reusing an old design or feature still usually requires JavaScript review and adjustment;
  • before development starts, it becomes clear what must stay and what can be simplified;
  • work happens in a test environment, so the public platform is not broken during development;
  • the client can decide whether to update only the technical foundation or also improve user experience;
  • key forms, pages, URLs and workflows are checked before launch.

When this is needed

  • the platform runs on Drupal 6 or Drupal 7;
  • security updates are missing or no longer realistic;
  • the old theme, modules or PHP version block maintenance;
  • existing functionality may be worth reusing, but it depends on old PHP or old Drupal logic;
  • the old design or interface behaviour depends on old JavaScript;
  • data storage, passwords, keys or encryption no longer match current expectations;
  • old passwords cannot be carried over from Drupal 6 or 7 in the same form because password hashing has changed;
  • the site has a lot of content, forms, users or custom functionality;
  • scope, risk and order need to be clear before work starts.

What WebPro maps

  • content types, fields, taxonomies, files and media;
  • users, roles, permissions and workflows;
  • modules, theme layer, custom code, old PHP logic and JavaScript behaviour;
  • forms, search, multilingual content, SEO URLs and redirects;
  • integrations, data exchange, payments or other business-critical connections;
  • sensitive data, passwords, keys and encryption-related areas.

How the work runs

  • we create a test environment and work from a backup;
  • we agree which content, forms and functions must work in the new version;
  • we prepare a migration plan and separate automated and manual parts;
  • we build a new Drupal 11 foundation and move content, configuration and required workflows into it;
  • when an old feature is worth reusing, we also assess the PHP upgrade and rewrite work it needs;
  • we check which JavaScript parts of the old design or interface can remain and which need rebuilding;
  • we check how users and sensitive data move, and plan the password reset workflow;
  • we test the most important user flows;
  • release is planned so the public platform is not left half-finished.

What to know before starting

With Drupal 6 and 7, it is rarely honest to promise that everything moves automatically one-to-one. In most cases this means building a new system and migration plan, not pushing the old code forward. A good workflow separates valuable content, technical debt, old PHP and JavaScript-related parts, the need to reset user passwords, data protection and the areas that should be rebuilt differently in modern Drupal.

Every migration is different. There is no single fixed method, because the plan depends on existing content, custom functionality, integrations, data and what must definitely remain in the new system. The key client question is usually simple: what must still work for visitors and editors when the new site goes live?

Next step: describe the current website, known Drupal version and what must remain in the new version.

Fill in the contact form