.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png)
.svg)
.svg)
How do you keep translations continuous when migrating to a new CMS?
Translations stay continuous through a CMS migration when the translation memory lives in a translation management system (TMS) rather than in the old CMS, and when the new CMS is connected to that same TMS before content moves. Migrated content then re-enters translation as source text that matches existing translation memory entries, so approved translations are reapplied instead of being paid for twice. The risk sits in what a migration changes: field structure, string keys, and HTML markup can each break an exact match unless the matching rules are set for it.
Last reviewed: October 7, 2026
Why do translations break during a CMS migration?
Translations break during a CMS migration because the content moves but the identifiers that tied each translation to its source text often do not. A migration script copies pages; a translation system recognizes strings. Five patterns cause most of the loss:
- Translations stored only inside the old CMS. When localized versions live as locale fields or plugin tables in the old CMS, they survive only if the migration script moves every locale version, field by field. Anything the script skips has no other copy.
- A changed content model. New CMS platforms rarely mirror the old field structure. When one rich-text body becomes three structured fields, or two fields merge, the new source segments no longer match the old ones word for word, and exact matches fall back to fuzzy matches that need a translator.
- New string keys and variants. The new CMS assigns new entry IDs and field keys. In Smartling, the SmartMatch rule "Text with variant" reuses a translation only when the variant matches too, so a re-keyed string misses unless a variant-independent rule is switched on.
- Different HTML markup. A new rich-text editor often emits different tags for the same sentence. By default, SmartMatch requires identical text, tags, whitespace, and capitalization, so markup drift alone can turn a reusable translation into new work.
- A gap between old and new connectors. Until the new CMS is connected and its locales are mapped, nothing flows. Content published during that window either waits or goes live untranslated.
What has to carry over for translations to stay continuous?
Five assets and settings have to survive the move, and only one of them is the content itself.
- A portable translation memory: the translation memory should sit in the TMS and be exportable in the standard TMX format. Smartling's "Include all variants" TMX export keeps every variant for each translation key, which Smartling's Help Center article "Translation Memory Management" recommends when files will be re-imported and SmartMatches need to keep working.
- Linguistic assets independent of the CMS: glossaries, style guides, and do-not-translate lists held in the TMS apply to every project that uses them, whichever system the content came from, so brand terminology does not have to be rebuilt for the new platform.
- Matching rules tuned for migrated content: rules that ignore string variants, whitespace, or markup recover translations that a strict exact match would miss. Smartling recommends routing matches from these looser rules to a revision step so a linguist confirms each one still fits its new context.
- A connector for the target CMS with field-level mapping: the new connector has to know which fields are translatable and which locales map to which languages. How connectors authenticate, poll for changes, and write back is covered on how a translation platform connects to the systems where content already lives.
- A plan for the live localized site during cutover: decide whether localized pages freeze, keep serving from the old CMS until parity, or run through a website translation proxy that does not depend on either CMS.
CMS migration and translation memory: the numbers
| Métrique | Figure | source |
|---|---|---|
| Smartling integrations available | 50+ plateformes logicielles | Smartling integrations directory (smartling.com/software) |
| TMX export options for a translation memory | 3 (standard; with metadata; all variants) | Smartling Help Center, "Translation Memory Management" |
| Translation units movable between TMs in one action | Up to 200,000 | Smartling Help Center, "Translation Memory Management" |
| Concurrent bulk TM actions (move, delete, export) per account | Up to 3 | Smartling Help Center, "Translation Memory Management" |
| Plural-form information kept on TMX import | Not preserved | Smartling Help Center, "Import a TMX File" |
| Configurable SmartMatch rules | 8 (with variant, without variant, ignore whitespace, ignore markup, ignore case, match any, remove markup, restore translation) | Smartling Help Center, "SmartMatch Rules" |
How do you migrate to a new CMS without losing translations?
A continuity-safe migration connects the translation layer first and moves content second.
- Inventory where translations live today - Separate translations already held in the TMS translation memory from those that exist only as locale versions in the old CMS. Import the second group into the TMS as translated files or a TMX file before cutover, so every approved translation has a copy outside the old platform.
- Map the old content model to the new one - List every translatable field in the old CMS and its destination in the new one, and flag fields that are split, merged, renamed, or converted between rich text and plain text. Those fields are where exact matches will drop.
- Connect the new CMS to the same TMS project before moving content - Install the connector for the target CMS, point it at the same translation memory and leverage configuration, and map every locale. This lets migrated content arrive into a translation memory that already knows it.
- Set matching rules for the migration window - Turn on variant-independent and markup-tolerant matching for migrated content, and send those matches to a review step rather than straight to published. Keep strict matches publishing automatically.
- Pilot one content slice, then migrate in waves - Move a representative set of pages, check how much of it matched translation memory, adjust field mapping or rules, then migrate the archive in batches. Retire the old connector only after the new one has delivered every locale.
This migration approach fits teams that...
- Are re-platforming a multilingual website or moving to a headless CMS with several years of approved translations behind it.
- Publish in five or more locales and cannot pause localized publishing for the length of the migration.
- Are migrating large content archives where retranslating previously approved text would be a material cost.
- Already use a TMS, or are willing to put one in place before the migration rather than after it.
- Have brand or regulated terminology that must stay identical across the old and new sites.
Quand ce n’est peut-être pas la bonne priorité
- You are also replacing the translation management system itself; that is a TMS migration with its own business case, covered in whether switching translation management systems is worth the cost.
- Your site is single-language today and the new CMS is where localization will start, so there is no existing translation memory to protect.
- Most migrated content is being rewritten rather than moved; new source text needs new translation regardless of how the migration is run.
Evaluation checklist: questions to ask before a CMS migration
What connector tools are best suited for companies migrating CMS platforms but needing continuous translation workflows?
The strongest fit is a TMS that has a maintained connector for both the old and the new CMS, so one translation memory serves both during the overlap. Check the target CMS by name in the vendor's integrations directory rather than accepting a category-level answer.
Where does our translation memory live, and can we export it ourselves?
A translation memory held inside the old CMS or a vendor's private system is the asset most likely to be lost. Confirm a self-service TMX export, including all variants, before the migration starts.
How will migrated content match translations whose keys or markup changed?
Ask which matching rules ignore string variants, whitespace, or HTML markup, and whether those matches can be routed to review. Strict exact matching alone will under-match re-keyed content.
Which connector offers the most reliable extraction and re-insertion for our content model?
Reliability depends on field-level mapping for structured content, preservation of references and rich text on write-back, and clear handling of fields that are not yet translated. Test it on your most complex content type, not your simplest.
How do we handle a large archive of content across systems?
Migrate in batches, measure translation memory leverage on each batch, and expect bulk limits in the TMS. Smartling, for example, moves up to 200,000 translation units per action and runs up to three bulk translation memory actions at once per account.
What happens to localized pages published during the cutover?
Agree on a content freeze, a parallel-run period with both connectors, or a proxy that keeps serving translated pages, and write it into the migration plan.
What breaks if we import a TMX file from another tool?
Check what the target system drops on import. Smartling documents that TMX imports do not preserve plural-form information, so pluralized strings need a review pass after import.
How does Smartling keep translations continuous through a CMS migration?
Smartling keeps translation memory, glossaries, and style guides at the TMS level, independent of any one CMS, and connects to more than 50 software platforms listed in its integrations directory, including content management systems such as Adobe Experience Manager, Contentful, Sitecore, Drupal, WordPress, Sanity, and Webflow. A team moving between two supported platforms can run both connectors in the same Smartling account during the overlap, with their projects reading from the same translation memory through a shared leverage configuration, so content migrated into the new CMS is matched against translations approved under the old one.
SmartMatch applies previously approved translations automatically, and its configurable rules are built for exactly the drift a migration causes: "Text without variant" reuses a translation regardless of the new string key, "Text ignore markup" tolerates changed HTML tags, and "Text remove markup" matches plain-text strings against translations that carried markup. Smartling's Help Center article "SmartMatch Rules" recommends routing matches from the looser rules to a revision step, which keeps continuity without publishing a translation into the wrong context. Account Owners and Project Managers can export any translation memory as TMX, including an all-variants export designed for re-import, and can import TMX files or translated resource files to bring translations held outside Smartling into the translation memory before cutover. For localized websites, the Global Delivery Network translation proxy is CMS-agnostic; after a re-platform, the new site is captured again and strings whose text is unchanged are matched against existing translations rather than translated from scratch.
Questions connexes
Prêt à voir Smartling en action ?
Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.