Changing a translation management system or CAT-tool environment is not a file-copy exercise. A localization platform can contain years of translation memory, terminology, segment status, context, comments, screenshots, workflow history, locale configuration, automation rules, project settings, vendor assignments and quality metadata. A migration that moves only the bilingual text can appear successful while quietly discarding the information that made the text trustworthy.
Searches for translation platform migration, TMS migration, CAT tool migration, TMX migration, TBX terminology migration, XLIFF interoperability, translation memory export, localization vendor migration, move translation memory between tools and localization data portability all point to the same professional job: preserve language assets, provenance and operational continuity while the software around them changes.
This guide explains how to migrate translation memories, termbases, bilingual projects, style guides, protected terms, comments, context and active work without turning the new platform into an unverified copy of old assumptions. It covers inventory, export formats, XLIFF, TMX, TBX, locale mapping, metadata loss, deduplication, segment status, user roles, API integrations, test imports, parallel runs, rollback, audit evidence and cutover. The objective is not to prove that two tools are identical. They are not. The objective is to preserve what matters and make every unavoidable difference explicit.
This article belongs inside eduKateSG’s Master Art of Translation architecture. It complements the existing owners for translation-asset backup and recovery, translation memory governance, terminology governance and project handoff. This page owns the controlled move between localization technology environments.
Quick answer: migrate meaning assets first, platform features second
A safe migration begins by identifying which information is organizational knowledge and which information is merely one tool’s implementation. Source-target segment pairs, approved terminology, definitions, locale identity, project provenance and final bilingual files usually belong to the organization. A proprietary quality score, custom dashboard or workflow state may not map directly. Export portable assets where possible, preserve native archives, document losses, test imports and verify real reuse before cutover.
- Inventory: know every asset and integration before exporting anything.
- Classify: portable data, tool-specific metadata, configuration and active workflow.
- Export: produce native backups plus standards-based or documented exchange files.
- Map: locales, fields, statuses, users, tags and metadata.
- Test: import a representative subset into a clean environment.
- Reconcile: compare counts, context, terminology and match behaviour.
- Cut over: freeze, delta-migrate, verify and retain rollback evidence.
1. Write a migration charter before touching data
A platform migration needs an explicit reason and success condition. The organization may be consolidating vendors, reducing cost, improving automation, changing security requirements, moving from desktop tools to a cloud TMS, or integrating localization into continuous delivery. Those goals determine what must be preserved and what can be redesigned.
Define scope: which business units, language pairs, active projects, historical memories, termbases, users and integrations are included? Define the target date and rollback window. Name the system of record during migration so two platforms do not both accept uncontrolled production changes.
Most importantly, define what “successful” means in language terms. The new tool should not merely open files. It should reproduce approved terminology, trustworthy reuse, active project state and target output at a level acceptable to translators and reviewers.
2. Inventory every localization asset
List translation memories, termbases, bilingual files, project templates, QA settings, segmentation rules, source filters, style guides, do-not-translate lists, reviewer comments, screenshots, client queries, user roles, automation scripts, APIs and delivery destinations. Include inactive assets that still have legal, audit or reuse value.
The inventory should identify owner, language pair or locale scope, current size, last update, trust level, sensitivity and whether the asset is still used. Migration is a good time to discover that three departments maintain competing “master” memories or that a deprecated termbase is still attached to live projects.
Do not migrate unknown assets blindly. Classify first. The cost of moving clutter is not only storage; it is future reuse of untrusted language.
3. Freeze a recoverable baseline
Before transformation, create a verified backup of the source platform. Native backups preserve tool-specific richness that portable formats may not carry. Portable exports provide an independent representation if the original platform later becomes unavailable.
Record export date, platform version, account or tenant, project scope and responsible person. Use checksums or another integrity method for critical packages if your operational environment supports it. A folder called “final backup” is weak evidence unless people know exactly what it contains.
Test restoration of at least a representative native backup before migration. The source system is your rollback anchor until the new environment has proved itself.
4. Separate portable standards from proprietary richness
Portable formats reduce tool dependency, but no interchange format automatically preserves every feature of every platform. XLIFF is designed to carry localizable data and metadata between localization steps and tools. TMX is widely used for translation-memory exchange. TBX, standardized in ISO 30042, is designed for terminology exchange. These formats are valuable precisely because they separate core language assets from one vendor’s interface.
However, platform-specific metadata may exceed the standard exchange model or be stored in extensions. Context hashes, workflow approvals, custom QA scores, machine-translation provenance and screenshot links can be lost or flattened.
Use standards for portability, native exports for richness, and a mapping document for the gap between them.
5. Export translation memories by trust level
Do not treat every memory as equally authoritative. Separate client-approved or production-approved memories from working memories, machine-generated drafts, personal translator memories and legacy imports. If those classes are merged during migration, the target system may promote weak suggestions as trusted reuse.
Preserve source language, target language, locale specificity, creation and modification dates where meaningful, creator or project provenance, usage counts if they matter, context information and approval status when the exchange path supports them.
If the target platform cannot represent one status model, create a translation rule. For example, only fully approved segments may enter the production memory while lower-confidence assets enter a secondary reference memory.
6. Clean memories before or during migration—carefully
A migration is an opportunity to remove duplicates and obvious corruption, but it is also a dangerous moment for aggressive cleanup. Two segments that look duplicated may differ by client, locale, context or effective date. A normalization script can erase meaningful distinctions.
Use the principles from the existing translation-memory hygiene owner: classify conflicts, preserve provenance and quarantine uncertain data rather than automatically choosing the newest or shortest variant.
Perform cleanup against a preserved source backup. Migration should never destroy the only copy of an ambiguous legacy decision.
7. Migrate terminology as concepts, not word pairs
A mature termbase contains more than source and target words. It can include concept IDs, definitions, subject fields, locale scope, preferred and deprecated terms, forbidden forms, grammar, notes, examples, source references and approval status.
TBX is valuable because it is concept-oriented, but target tools differ in how they map fields. Build a field map before import. If the target platform lacks a native field, decide whether to store the information in notes, a custom field, an external terminology system or an archived companion export.
In 2026, ISO 30042:2019 remains the current published TBX standard while a third edition is under development, and ISO/TR 24633-1:2026 provides a newer companion overview. Record the exact format and version used in your migration package.
8. Preserve locale identity precisely
Platforms use different language-code conventions. One system may store Portuguese (Brazil) as pt-BR, another as an internal numeric ID, another as pt_BR, and a legacy memory may say simply Portuguese. These differences can silently merge or split assets.
Create a locale mapping table before import. Include source code, target code, script, region, parent locale and whether cross-locale reuse is allowed. Do not map unknown generic language data into a specific regional locale without review.
Test the actual target platform’s locale model. A visually similar label in the interface does not prove the underlying identifiers or fallback behaviour are equivalent.
9. Preserve context or lower reuse trust
Context tells a translation memory whether the same source sentence appears in the same structural environment. Different platforms calculate context from file paths, preceding segments, resource keys, document structure or proprietary hashes. A migrated TM may lose those signals.
If exact context cannot migrate, document the change and lower automatic trust accordingly. A “101% context match” in one platform may become a plain 100% text match in another. That is not necessarily a failure, but it changes review policy.
Run representative projects in both systems and compare match categories. Do not assume identical percentages mean identical evidence.
10. Map segmentation rules
Translation memories depend on how source content is divided into segments. Different sentence-breaking rules can make a clean TM appear unusable after migration. Abbreviations, punctuation, line breaks and language-specific rules all influence segmentation.
Export or document custom segmentation rules. Import them where the target system supports equivalent configuration. Test source files known to contain edge cases such as initials, decimal numbers, abbreviations, lists and headings.
If exact segmentation cannot be reproduced, quantify the effect. You may need to realign critical bilingual data or accept lower matching until the new memory rebuilds context.
11. Rebuild file filters and extraction rules
A localization platform decides which parts of XML, JSON, YAML, HTML, office documents or proprietary formats are translatable. Custom filters can contain years of learning about protected nodes, embedded tags and content exceptions.
Document source filters separately from translation memory. A perfect TM is useless if the new platform extracts code as text or omits user-facing fields. Use golden source files and compare extracted segment counts and samples between old and new systems.
Where the new tool’s filter model differs, translate intent rather than copying settings mechanically. The target configuration should preserve the content boundary, not the appearance of the old settings screen.
12. Migrate active bilingual projects with version identity
Historical TM assets are relatively static. Active projects are harder because translators may continue editing while migration occurs. Each bilingual file must remain tied to the correct source revision and workflow state.
Plan a freeze or controlled delta window. Export active bilingual work at a known timestamp, prevent uncontrolled edits in the old platform, import and verify the target project, then reconcile any emergency changes created during the freeze.
Never recreate active projects from target-only documents if bilingual state exists. Alignment, tags, comments and unresolved queries can be lost.
13. Decide what happens to comments and queries
Translator questions, reviewer comments and client decisions often contain the rationale behind unusual language. Those conversations may be stored at segment, document or project level and may not export through standard bilingual formats.
Classify which discussions are operational noise and which are durable decisions. Export important decisions into a migration ledger or decision log if the target platform cannot preserve them natively.
A target translation without its rationale can be dangerous when the next reviewer “corrects” a deliberate exception back to the wrong default.
14. Rebuild user roles from responsibility, not old permissions
Platforms use different permission models. The old system’s “project manager” role may bundle capabilities that the new system separates. Copying role names is therefore weaker than mapping actual responsibilities.
List who needs to create projects, see confidential content, edit source, translate, review, approve terminology, manage vendors, export data and publish integrations. Apply least privilege in the target environment.
Migration is a good time to remove inactive users and expired vendor access, but retain audit requirements where policy demands it.
15. Rebuild integrations as contracts
A mature TMS may connect to Git, CMS platforms, design tools, support systems, file storage, machine translation, identity providers and analytics. The visible connector is only one part of the contract. Field mapping, triggers, authentication, branch rules and failure behaviour matter.
Document what each integration consumes and produces. Record source-of-truth direction, sync frequency, retry behaviour, error alerting and which metadata must survive. Then rebuild the contract in the new tool rather than checking a box called “connect.”
Run failure tests. Disconnect the connector, change a field, rename a branch or remove a permission and verify that the new system fails visibly rather than silently dropping content.
16. Test import on representative data before bulk loading
Choose a pilot set that contains the difficult parts of the estate: multiple locales, rich metadata, old and new TMs, terminology with custom fields, tagged files, comments, plural messages, long documents and active projects. A clean marketing brochure is not a sufficient migration test.
Import into a sandbox. Compare record counts, locale identity, status distribution, term fields, context, fuzzy-match behaviour, file reconstruction and user permissions. Record every difference as accepted, fixable or blocking.
Only after the pilot passes should bulk migration begin. The purpose of the pilot is to discover mapping errors while they are still cheap to reverse.
17. Compare retrieval behaviour, not only record counts
Two TMs can contain the same number of segments and still behave differently. Tokenization, penalties, context matching, tag handling and fuzzy algorithms vary by platform. A numerical inventory cannot prove equivalent translator experience.
Run a benchmark set of real source documents through old and new systems. Compare exact matches, context matches, fuzzy suggestions, terminology hits and false positives. Ask experienced translators whether high-value suggestions remain visible and trustworthy.
Where behaviour changes, adjust thresholds and review policy. Do not force the new tool to imitate every old score if its matching model is genuinely different.
18. Validate terminology recognition after import
A termbase can import successfully while recognition fails because language fields, tokenization, morphology or case settings changed. Test real source sentences containing inflected forms, abbreviations and multiword terms.
Confirm preferred, forbidden and deprecated status appears correctly. Check definitions and notes, not only term hits. If the platform cannot represent one field, ensure translators know where that information moved.
Terminology migration is complete only when the target environment helps translators make the same or better lexical decisions.
19. Run a parallel production period where risk justifies it
For high-value localization programs, a short controlled parallel run can expose differences before the old platform is retired. Process the same representative job in both environments, then compare output, reuse, QA findings and turnaround.
Parallel work should be bounded. Running two production systems indefinitely creates dual sources of truth. Define what the test is supposed to prove and when the old environment becomes read-only.
Use the comparison to refine target configuration, not to demand superficial sameness. The new system may improve workflow while still preserving the underlying language assets.
20. Plan the final delta migration
Even after a bulk import, new segments, terms and decisions continue accumulating in the old platform. The final cutover needs a delta plan: identify everything changed since the baseline snapshot and move only those changes.
Freeze source production at an announced time, export delta assets, import them, reconcile conflicts and verify counts. Avoid repeating the entire migration unless necessary, because duplicate imports can create additional conflicts and obscure provenance.
Keep the old environment read-only for a defined period if licensing and policy allow. It can serve as an audit reference while the new platform stabilizes.
21. Keep a migration-loss register
No complex platform migration is perfectly lossless. The professional response is not to hide differences but to record them. A migration-loss register lists fields, behaviours or history that could not be transferred exactly, explains the consequence and records the chosen mitigation.
Examples include lost screenshot links, flattened approval statuses, missing legacy user identities, changed fuzzy-match scores or unsupported custom term fields. Some losses are harmless; others change review or audit requirements.
This register becomes part of project provenance. Future teams know why the new environment differs instead of rediscovering gaps years later.
22. Do not decommission until recovery has been proved
The target platform should complete real production cycles before the source system is irreversibly closed. Confirm that translators can work, reviewers can approve, integrations can deliver, terminology appears, memories return useful matches, audit evidence is sufficient and backups of the new platform exist.
Export a final source archive and preserve it under retention policy. Record decommission date, responsible owner and how historical data can be accessed if required.
A migration ends when the organization can operate and recover confidently in the new environment—not when the last import progress bar reaches one hundred percent.
A repeatable migration sequence
- Write the business and language success criteria.
- Inventory all assets, integrations and active workflows.
- Create and test a recoverable source-platform baseline.
- Classify assets by trust, sensitivity and portability.
- Export TMs, terminology and bilingual data in native and portable forms.
- Build locale, metadata, status and field mappings.
- Recreate segmentation and extraction rules.
- Import a representative pilot into a sandbox.
- Compare retrieval, terminology and file reconstruction.
- Document accepted and blocking differences.
- Rebuild permissions and integrations.
- Run bounded parallel production where risk justifies it.
- Freeze the old system and migrate the final delta.
- Verify production, backups and rollback.
- Make the old platform read-only, then decommission under policy.
Worked scenarios
Scenario 1: moving five years of approved TM to a new TMS
The organization exports a single TMX containing five years of data and imports it successfully. Segment counts match, but context-match rates collapse because the old system used proprietary context hashes. The migration team documents the loss, lowers automatic acceptance thresholds, preserves the native archive and lets the new platform rebuild context gradually from fresh projects.
Scenario 2: terminology custom fields do not map
The old termbase stores definition, subject field, regulatory jurisdiction, forbidden term and product version. The target platform supports only definition and status. Rather than discarding data, the team maps essential operational fields into structured notes and preserves the full TBX export as the authority until a better terminology system is chosen.
Scenario 3: active projects continue during migration
A week-long bulk migration begins while translators continue editing the source platform. The team records a baseline timestamp, then exports a final delta of segments and terms modified after that point. Conflicts are reviewed rather than simply letting the last import overwrite earlier target data.
Scenario 4: CMS connector maps the wrong field
The new connector sends internal product codes as translatable text and omits image alt text. A pilot project catches the mismatch before bulk rollout. The team rebuilds the content mapping contract and adds a regression test comparing extraction against a golden source entry.
Scenario 5: user permissions become too broad
The old “reviewer” role had narrow document access, while the new platform’s default reviewer role can see all client projects. A role-name mapping would create a confidentiality problem. Responsibility-based permission design avoids that by assigning only the specific projects and actions each reviewer needs.
Scenario 6: the new platform reports higher fuzzy matches
Management assumes higher percentages mean better reuse. Translators find that some high scores are less contextually reliable than lower scores in the old system. The team compares real documents, adjusts thresholds and trains users on the new matching model instead of treating percentages as universal units.
Twenty migration checks
- Can the source system be restored from backup?
- Are production and working TMs separated?
- Are locale codes mapped explicitly?
- Do TM exports preserve provenance and status?
- Do terminology exports preserve concept metadata?
- Are segmentation rules documented?
- Are file filters reproducible?
- Do bilingual project files remain tied to source versions?
- Are important comments and decisions preserved?
- Do target permissions match actual responsibilities?
- Are API and CMS integrations mapped field by field?
- Does a pilot include difficult real content?
- Do segment counts reconcile?
- Does match behaviour remain useful?
- Does terminology recognition work in context?
- Are unsupported metadata fields documented?
- Is there a final delta-migration plan?
- Can the new environment roll back or recover?
- Is the old system read-only before decommission?
- Does the migration-loss register explain every material difference?
Release checklist
- Migration success criteria are written.
- All language assets and integrations are inventoried.
- A recoverable source baseline exists.
- Native archives and portable exports are both preserved where useful.
- TM trust levels remain separated.
- Terminology fields and statuses are mapped.
- Locales and scripts are mapped without silent merging.
- Context and segmentation changes are understood.
- File filters reproduce translatability boundaries.
- Active projects have a controlled freeze and delta plan.
- Permissions follow least privilege.
- Integrations have failure tests.
- Pilot retrieval and terminology behaviour are verified.
- Known losses are documented.
- Production and recovery are proven before decommission.
Frequently asked questions
Is TMX enough to migrate a translation memory?
TMX is valuable for portable segment exchange, but tool-specific context, workflow state or custom metadata may not transfer completely. Preserve native backups and test actual import behaviour.
What is XLIFF used for?
XLIFF is an OASIS standard for carrying localizable data and related metadata between steps and tools in a localization process. It is useful for project interchange, but implementations still need mapping tests.
What is TBX?
TermBase eXchange is an ISO-standardized framework for exchanging terminological data. It is concept-oriented and can preserve richer terminology structure than a simple bilingual spreadsheet.
Should we clean the TM before migrating?
Clean obvious corruption and duplicates carefully, but preserve provenance and avoid destructive bulk normalization. Keep a recoverable copy of the pre-cleaned source.
Why do fuzzy-match scores change between tools?
Platforms can use different tokenization, penalties, context models and matching algorithms. Compare real retrieval usefulness instead of treating percentages as universal equivalents.
How long should the old platform remain available?
Long enough to verify production, reconcile deltas, satisfy audit needs and prove recovery in the new system, subject to licensing, security and retention policy.
Should every historical project be migrated?
Not necessarily. Some inactive projects are better archived in portable and native formats, while current memories and governed terminology enter the production target system.
What is the biggest migration risk?
Assuming successful import equals successful migration. Language assets can arrive while context, trust, terminology, permissions or integrations quietly degrade.
Selected references
- OASIS XLIFF Version 2.1 — interchange of localizable data and metadata between localization processes and tools.
- ISO 30042:2019 — TermBase eXchange (TBX).
- ISO/TR 24633-1:2026 — Companion to TermBase eXchange, Part 1.
- eduKateSG: Back Up Translation Memories, Termbases and Project Assets.
Conclusion: interoperability is a tested capability, not a checkbox
A localization platform migration is successful when the organization can still explain where its language came from, why it is trusted, which locale it belongs to, how it is reused and how active work continues. That requires more than moving text. It requires preserving relationships between text, context, terminology, status, source versions and human decisions.
Portable standards reduce dependence on one tool. Native archives protect richer platform state. Pilot imports expose mapping gaps. Parallel tests show whether retrieval still helps translators. A migration-loss register keeps unavoidable differences visible. Together, those controls let the software change without forcing the organization to relearn its own language history.