Why a multilingual Drupal 7 migration is a rebuild with translation checks
If your multilingual Drupal 7 site is still running, you are on a platform whose security support ended on January 5, 2025, and the move to a supported version is now a rebuild, not an upgrade. Drupal 6 and 7 sites are migrated into a new site rather than updated in place, and every translation needs its own verification after the move. The Drupal.org upgrade guide covers this path and has separate sections for multilingual Drupal 6 and multilingual Drupal 7 sites, so start there before you estimate anything. Themes cannot be migrated and must be rebuilt, which adds work on top of the content and configuration moves.
The effort depends less on the total page count than on four things: which translation module the site used (content translation or entity translation, since they store translated data differently), how many languages are enabled, how many fields carry translated values, and how many menus and taxonomy vocabularies have translations of their own. Ask your team or a partner to inventory each of these before agreeing a scope. Confirm with your own data which translation module is in use and whether any content was translated through custom code, because that code will need a replacement plan.
Plan for the security position while the work is underway. Drupal 7 security support ended on January 5, 2025, and the Drupal Association's extended support program lists certified vendors for sites that cannot migrate yet. Ask your decision makers to compare that cost with the cost of finishing the migration, and treat the multilingual checks as a release gate rather than a final tidy-up, since a language that is missing or mislinked on launch day is hard to notice and easy to explain away later.
What maps cleanly from Drupal 7 multilingual sites and what does not
This table compares each multilingual building block on a Drupal 7 site with its Drupal 11 counterpart and notes what the migration carries over, what needs rebuilding and what to check. Read the rows as a checklist: anything marked for confirmation depends on your own site configuration, not on general Drupal behavior, so verify it against a copy of your database before you sign off the plan.
| Source capability | Drupal 11 equivalent | Migration note |
|---|---|---|
| Language list and negotiation | Core language and language detection settings | Languages and detection order should be recreated and tested. Confirm each language code and its enabled state on your site. |
| Content translation (node translation) | Core content translation | Translation sets usually move with their source nodes. Check that every translated node links back to the correct source node. |
| Entity translation | Core content translation for supported entities | Entity Translation has no direct one-to-one target. Confirm which entity types and bundles were translated, then map each one explicitly. |
| Translated fields | Translatable fields on the matching content type | Field translatability must be set on the new site before content loads. Untranslated values need a defined fallback rule. |
| Translated menus | Menu links with language-specific content | Menu links are rebuilt per language. Confirm that each language menu renders its own links and that no links point to the default language by mistake. |
| Translated taxonomy terms | Taxonomy term translation | Term translations and their references should be checked in each language. Confirm that term relationships and hierarchies survived the move. |
| URL aliases, including language-specific aliases | Path aliases with language assignment | Language-specific aliases may not carry over as expected. Test every translated URL and set redirects for any changed paths. |
| Themes and language switcher | Themes rebuilt on current Drupal | Drupal 7 themes cannot be migrated and must be rebuilt. Confirm the language switcher and any language-based templates in the new theme. |
Documented migration tools for Drupal 7 multilingual content
Drupal.org documents a small set of migration paths for Drupal 7 sites, and each handles translations to a different depth. The cards below describe what each path covers, where translation data needs manual checks, and why contributed modules must be verified against your exact Drupal and translation setup before you rely on them.
Core Migrate and Migrate Drupal modules
The core Migrate, Migrate Drupal and Migrate Drupal UI modules form the documented path for moving a Drupal 7 site into a new Drupal installation. They read the Drupal 7 database and map language settings, nodes, taxonomy and fields into the new site. Translation coverage depends on how the source was built, so confirm which language, node and field translation records the migration maps in your version, and reconcile counts per language after each run.
Drush-based migration
Drush lets you run the same Drupal 7 migration from the command line, which suits repeatable test runs and scripted cutovers. It is useful for re-running a migration against a fresh copy of the source database while you check translated content. Keep the migration definitions and run logs under version control so each rehearsal can be compared with the last, and confirm the Drush commands available in your target release before you script them.
Multilingual Drupal 7 upgrade sections
The Drupal.org upgrade guide has separate sections for multilingual Drupal 6 and multilingual Drupal 7 sites, so the language setup is documented apart from the general upgrade steps. Read the Drupal 7 section against your own configuration, including whether you used content translation, entity translation or both. Note which language negotiation, URL prefixes and translated menus the guide covers, and record any gap as a manual task.
Themes are rebuilt, not migrated
Drupal.org documents that themes cannot be migrated from Drupal 7 and must be rebuilt. For multilingual sites this affects language switchers, translated block placement, right-to-left layouts and any templates that print translated labels. Inventory every translation-dependent template and block before planning the rebuild, because content can migrate correctly while the new theme still shows the wrong language or missing switcher.
Contributed translation modules
Contributed modules exist for specific Drupal 7 translation setups, such as entity translation and field-level translations that the core paths do not map. Their Drupal 10 and 11 support, maintenance status and data mapping vary between projects. Before use, verify the module's compatibility with your target Drupal version, check its release history, and test it on a copy of your translated content.
Post-migration translation checks
No documented path proves that every translation arrived intact, so build the verification step yourself. Compare node counts, translation sets, menu link translations and taxonomy term translations per language between source and target. Sample pages in each language for missing fields, wrong fallback text and broken hreflang or URL aliases. Record the results so that the cutover decision rests on evidence, not on a clean migration log.
How translated nodes, fields and menus move between the two versions
The first decision is whether the translations of a node arrive as one translation set or as separate nodes that happen to share a source ID. On a Drupal 7 site that used the Entity Translation or Content Translation approach, each translated entity carries a language code, and the migration has to map those codes to the language entities that exist on the new site. Confirm every language mapping before the first run, including the undefined or language-neutral case, because a mismatch often does not fail loudly. It simply attaches Spanish text to the English translation set, or leaves fields blank. Check the language list in the target site's configuration, then compare it against the codes in the source database for each content type, field and bundle. Ask whether the source node IDs should be kept. Keeping them makes redirects, links in body text and external references easier to trace, but it can conflict with IDs already assigned on a new site. Decide this before the test run, and write down how the mapping of source to destination IDs will be stored so rollbacks remain possible.
Translated fields need their own verification pass. Each translated field value, including text formats, file references and entity references to other translated content, must be checked against the source for at least one node per language, because references can point to the default-language version of an entity when a translation was expected. Menu links and taxonomy term translations follow different rules and are frequently the first things editors notice. Menu link translations, the menu structure and the parent-child relationships between links must be compared language by language, and any menu item whose target node did not migrate needs a planned fix. Taxonomy terms that were translated as separate terms rather than as translations of one term will appear as duplicates on the new site unless they are merged deliberately. Avoid assuming complete coverage. Keep a register of the content types, fields and menus you tested, and treat anything outside that list as unverified until someone has checked it.
How the migration runs from inventory to decommission
The sequence moves a Drupal 7 multilingual site through inventory, a rebuilt target, a one-language pilot, full translated runs, a parallel period and cutover, so each stage produces evidence before the next one starts. It ends with the Drupal 7 site retired and any extended support contract closed.
Inventory languages, translation modules and fields
Record every language enabled on the Drupal 7 site, the translation approach in use (content translation or entity translation), each translated content type, field, taxonomy vocabulary and menu, and any custom code that reads or writes translations. The DeployOpen team and your site owners review this list together, and the output is a signed-off inventory that states which entities carry translations and which do not. The step is done when every translated entity type has an owner and a target treatment.
Build the target site and rebuild themes
Stand up the new Drupal site on a supported core version, with the languages, language detection rules and content translation settings matched to the inventory. Themes cannot be migrated from Drupal 6 or 7, so the front end is rebuilt against the new site and checked for right-to-left support and language switcher behavior where those apply. The step closes when the empty target site installs cleanly, the language configuration matches the inventory, and the rebuilt theme renders in every language.
Run a pilot migration on a copy with one language
Restore a copy of the Drupal 7 database and files into a separate environment, then run the core Migrate, Migrate Drupal and Migrate Drupal UI path (or Drush) for one language and a small set of translated nodes, taxonomy terms and menu links. Compare source and target field by field, including translation status, revision and URL alias output. The pilot is complete when the team has a written list of mapping gaps and each gap has an agreed fix or manual rebuild task.
Run full migrations with translation checks
Apply the fixes from the pilot and run the migration against the full copy for all languages. After each run, check translated node counts against the source, confirm each translation links to the correct source entity, verify menu and taxonomy translations, and review fields that did not carry over. Each run is recorded with its output and exceptions. The step is done when a run completes with exceptions that are all explained and accepted by the site owner.
Operate a parallel run with synchronized content
Keep the Drupal 7 site live while editors work in the new site in a controlled period, and decide in advance which system is the editing source for each content type. Repeat incremental migrations so content changes on the old site reach the new one, and track any content edited in both places. The step is done when the agreed sync cycle has run cleanly and editors have signed off translated pages in each language.
Cut over with redirects and hreflang review
Freeze editing on the Drupal 7 site, run the final incremental migration, and point the public domain at the new site. Map every legacy URL, including language-prefixed paths, to its new destination with redirects, then review hreflang annotations, canonical tags and the sitemap for each language. The cutover is verified when sampled URLs in every language return the expected page and the search engine references point to the right language versions.
Decommission Drupal 7 and any extended support contract
After the new site has run stably in production, archive a final copy of the Drupal 7 database, files and configuration under your retention policy, then shut the old site down. If you bought extended security support from one of the certified vendors listed by the Drupal Association, confirm the end date with that vendor and cancel the contract once the old site is retired. The step closes with a written decommission record covering archive location, access controls and the contract status.
What drives the cost and duration of a multilingual migration
This table lists the factors that change the effort of a Drupal 7 multilingual migration, why each one matters, and what to ask for in a written quote. Read each row as a question to answer about your site before comparing proposals, since most of these drivers are fixed by your current content and code rather than by the migration method.
| Driver | Why it changes effort | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Number of languages | Each language adds language configuration, translated paths, menu links, and a verification pass on every content type. | One-time | Per-language scope, with the content types and menus covered in each language. |
| Translation module in use | Content Translation and Entity Translation store translations differently, so the mapping and test effort differ. | One-time | Which module the source site uses, and how the plan maps its translation tables. |
| Count of translated fields and entity types | Translated fields on nodes, users, taxonomy terms and custom entities each need their own mapping and checks. | One-time | A list of translated entity types and fields, with the mapping approach for each. |
| Custom modules needing rewrites | Custom code that reads D7 translation APIs or hooks must be rewritten for Drupal 10 or 11 before it works. | One-time, plus ongoing maintenance of custom code | Inventory of custom modules, with those that need rewriting and those to retire. |
| Theme rebuild scope | Themes cannot be migrated, so templates, language switchers and translated blocks are rebuilt by hand. | One-time | Number of templates and components to rebuild, and how language switching is styled. |
| Views and Webform dependencies | Translated Views listings and multilingual Webforms often need manual rebuilding after migration. | One-time | Inventory of translated Views and forms, and which will be rebuilt rather than migrated. |
| SEO and redirect requirements | Translated URL aliases, hreflang output and redirect maps must be preserved and tested to protect rankings. | One-time setup, with ongoing monitoring | Redirect map scope per language, hreflang handling, and post-launch monitoring. |
| Content volume | Larger node counts and revision histories lengthen migration runs, reconciliation and validation. | One-time | Node, revision and file counts per language, and the approach to old revisions. |
| Hosting and upgrade path | The target platform and PHP version change how many intermediate steps the migration needs. | Recurring when the platform is upgraded | Target Drupal and PHP versions, and the support arrangement after launch. |
What usually goes wrong with translations after migration
Multilingual Drupal 7 sites fail in quiet ways. Content may arrive without its translations, links may point at the wrong language, and menus or taxonomies may look correct in one language while the others drift. Each risk below has a prevention step during the build and a check that should catch it before cutover.
Missing translations after import
Nodes migrate in their source language, but translated entities can be dropped or attached to the wrong language when the source site used content translation or entity translation. Prevent this by confirming the language list and translation mode on the Drupal 7 source before mapping. Check it by comparing translation counts per content type and language between the source database and the new site, sampling nodes in every language.
Broken translation sets
A translation set ties a node's language versions together through its translation source and shared identifiers. If those links break, editors see separate unrelated nodes and language switchers stop working. Map the translation identifiers explicitly in the migration, then check that each translated node reports the same set of language versions on the new site as it did on the old one.
Language-specific URL aliases lost
Path aliases are often set per language, so a German alias may be missing or fall back to the English path after the move. Visitors and search engines then hit 404s on URLs that were indexed. Migrate aliases with their language codes, then crawl the old URL list against the new site and confirm each one resolves in its own language.
Hreflang errors after cutover
Hreflang annotations depend on the translation set and the alias of every language version. If either is wrong, alternates point at missing pages or at the wrong language, and search engines may ignore the annotations. Generate the tags from the migrated translation sets, and test a sample of pages after cutover for reciprocal alternates pointing to live URLs.
Untranslated menus and blocks
Menu links and block titles sit outside the node translation model, so they often migrate in the default language only. Visitors then see translated articles inside an English navigation. Plan a translation pass for every menu, block and site configuration string, and check each language version of the main navigation and footer by hand.
Duplicated taxonomy terms
When terms are translated, the migration can create a new term for each language instead of linking translations to one term. Content then lands on different terms, and filtered listings split. Confirm the term translation mapping in a test run, count terms per vocabulary before and after, and review any term names that appear twice.
Unsupported contributed modules
Some translation-related contributed modules from Drupal 7 have no direct equivalent on current Drupal, so their behavior must be rebuilt or replaced. Inventory every contributed module that touches languages during discovery, decide its replacement, and test language switching, forms and search in each language before go-live.
Questions teams ask before migrating a multilingual Drupal 7 site
What drives the cost of migrating a multilingual Drupal 7 site?
The main cost driver is how much translated content and configuration the site carries, and how much of it can be moved automatically. The number of languages, the translation method (content translation or entity translation), the count of translated nodes, fields, menus and taxonomy terms, and the amount of custom code all affect effort. Themes are never migrated, so a rebuild is a cost in every case. Ask any partner for a quote built from a written scope that lists these inputs, and separate one-time work (planning, mapping, build, testing, launch) from recurring work (hosting, updates and support after launch).
How long does a Drupal 7 multilingual migration take?
Duration depends on the same inputs as cost: languages, translated volume, custom modules, Views, and the theme rebuild. Teams usually lose the most time on translation mapping and on content that does not match between languages, not on the copy itself. Ask for a timeline in the written scope with separate phases for discovery, a trial migration, translation checks and launch. Any timeline you receive should state the assumptions behind it, such as who supplies translations and who signs off each language.
When should we start planning relative to Drupal 7 end of support?
Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so sites on Drupal 7 no longer receive core security releases from the community. Planning should begin now rather than at the point of a incident or audit. Migration is a new site build, not an in-place upgrade, so it needs time for content modeling, translation review and testing. If you cannot migrate yet, the Drupal Association's extended security support program lists certified vendors, including HeroDevs and Tag1 Consulting, who provide patches for a fee.
What does our team need to provide for a multilingual migration?
Plan for named owners in each language, a decision-maker for the language list and the content model, and access to the Drupal 7 source, database backup and file store. Translators or translation managers must confirm which strings and nodes are live, which translations are stale and which are missing. Your team also needs to approve the target content model, URL and redirect plan, and the list of languages and their fallback rules. Without these inputs, the migration will copy problems forward.
Can an internal team migrate a multilingual Drupal 7 site alone?
An internal team can do it if it has Drupal developers who have used the core Migrate, Migrate Drupal and Migrate Drupal UI modules, or Drush, and if it can rebuild the theme and the custom code. The hardest parts are translation mapping, verifying translated fields and menus, and rebuilding Views and custom modules that do not migrate. Ask whether the team has done a multilingual migration before, how it will run a rollback test, and who owns the work after launch. Many organizations choose a partner for the planning and verification phases only.
How do we verify translations after a Drupal 7 migration?
Start by comparing counts per language for nodes, fields, menu links and taxonomy terms between the source and target sites. Then sample translated pages in each language, checking that the right translation, the right URL alias and the right language code are attached to each entity. Test language switching, fallback behavior, hreflang output and redirects from old URLs. Finally, have native speakers review a defined set of pages and the navigation. Record each check in a sign-off sheet so the decision to launch is traceable.
What is the Drupal 7 extended security support option and how does it compare to migrating?
Extended security support is a paid option from certified vendors that patches known vulnerabilities while you stay on Drupal 7. The Drupal Association's extended security support program lists HeroDevs and Tag1 Consulting as the certified vendors. It buys time but does not add features, does not move the site to a supported platform and does not remove the need for a migration. Compare the vendor's fees and the length of coverage you need against the cost and schedule of migrating now. Ask each vendor what it covers, how it delivers patches and what it requires from your team.
Official Drupal.org sources for the migration
Start the planning phase with the Drupal.org upgrade guide for multilingual Drupal 7 sites, which has its own section separate from the single-language path. Read it alongside the general guidance on upgrading from Drupal 6 or 7, because it sets out the baseline the migration depends on: a Drupal 6 or 7 site is not updated in place to a current release. It is migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes are rebuilt rather than carried over. Your team should check the guide's multilingual section against your current site's language setup before scoping, including which translation approach the site used, since that determines what the migration must map.
Use the Drupal core release schedule to fix your target version and your deadlines. Confirm which Drupal 11 and Drupal 12 dates apply on the day you sign the scope, because the schedule changes and your plan should reference the current entries. Pair it with the Drupal 7 end of life extended support partners page, which lists the certified vendors offering extended security support for sites that cannot yet migrate. If the migration will take longer than the business can wait, that page is the reference for the interim cost and the vendors' terms, which you should request in writing.
Finally, check the PHP requirements page against the hosting you plan to use for the new site. The required PHP version differs by Drupal major version, and no supported release runs on PHP 7, so the target hosting image, container base or managed platform must be confirmed before build work starts. Record the versions you verify, the date you checked them and the person who approved them, so that the migration plan, the hosting specification and the translation testing all refer to the same platform baseline.
How DeployOpen scopes and delivers a multilingual Drupal migration
DeployOpen plans and builds Drupal 7 multilingual site migrations as fixed-scope work agreed in writing before the build starts. We scope the translation model, migrate into a new Drupal site, test each language and hand over documented steps your team can run and maintain.
How we scope
- Inventory which translation module the Drupal 7 site used, such as content translation or entity translation, and every enabled language.
- Map translated nodes, fields, menus, taxonomy terms and URL aliases that must carry across to the new site.
- Agree in writing which theme elements are rebuilt, since Drupal 7 themes cannot be migrated and must be recreated.
How we build
- Configure languages and content translation on the target Drupal site before running the migration.
- Run the core Migrate, Migrate Drupal and Migrate Drupal UI modules, or Drush, against a copy of production data.
- Compare translated nodes, menus and taxonomy per language in a staging environment and log each mismatch for correction.
How we hand over
- Deliver a written record of the language configuration, field mappings and any custom migration code.
- Provide a checklist of post-migration checks per language, covering hreflang, redirects and translated menu links.
- Walk your editors and site builders through translation workflows on the new site and record the open issues.
How we support
- Offer ongoing support, upgrades and testing as a retainer after launch, scoped separately from the migration.
- Plan the path from the new site's Drupal version onward, including the release cadence your team needs to follow.
- Confirm with your team which hosting, PHP and database versions the new site will run before the work is scheduled.
