On this page
Multilingual websites raise the stakes of every migration decision. Each page may exist in several languages, each with its own URL, metadata and audience. Drupal has strong built-in language support, and sites built on it often rely on several layers of that support at once. Mapping those layers is the first step.
Understand the layers of translation
Drupal separates several kinds of translatable material:
- Content translation: nodes, media and taxonomy terms translated field by field.
- Configuration translation: labels of menus, views, blocks and fields.
- Interface translation: strings in templates and modules, such as button labels.
A migration needs a plan for each layer. Content translations are the most visible, but missing interface strings make a site feel half translated.
Record how languages appear in URLs
Language negotiation determines how Drupal decides which language to serve. Common approaches are a path prefix, a separate domain or subdomain per language, or detection based on browser settings. Record the current approach and every language code in use. Keeping the same URL pattern on the new site simplifies redirects considerably.
Preserve translation relationships
In Drupal, translations of a node are linked to their source. That relationship is what powers language switchers and hreflang annotations. When importing into a new system, make sure each translation is connected to its counterpart rather than imported as an unrelated page.
Check for partial translations
Not every page is translated into every language. Decide how the new site will behave when a translation is missing: hide the language switcher option, link to the source language or show a notice. Document the current behavior so the change is intentional.
Plan hreflang and metadata
Search engines use hreflang annotations to understand language alternatives. Confirm whether the current site outputs them, and ensure the new site generates correct annotations for each translated page, including a self-reference. Titles and descriptions should be translated too, not copied from the source language.
Translation workflows
Find out how translations are produced today. Some teams translate in the CMS, others export content to translators and import the results. The new platform should support whatever process the team relies on, or a better one agreed in advance. Include translators in testing, since they will notice problems others miss.
Right-to-left and character considerations
If any languages are written right to left, the design system must support mirrored layouts. Check that fonts cover all required characters, and that search, sorting and slugs handle them correctly.
Test each language as its own site
Run the same checks for every language: navigation, key pages, forms, redirects and metadata. Language-specific forms may route to different teams or send confirmations in the visitor's language.
Keep scope realistic
Multilingual migrations take longer than single-language ones because every decision multiplies. Prioritise languages by audience and business importance, and agree whether all languages launch together or in phases. A phased approach can reduce risk, provided redirects and language switchers handle the interim state cleanly. Whichever route you choose, write the language plan down and share it with editors, translators and anyone responsible for regional marketing, so everyone knows which versions will be live on launch day and which will follow.
Turn this topic into a project plan
Use these supporting guides to prepare the details for your drupal discussion.
Put this into practice
Planning a move like this?
See how a scoped drupal migration project handles content, URLs, integrations and launch.