TMS Migration Guide: How to Switch Translation Platforms Without Losing Data

Why Teams Migrate Translation Management Systems

Translation management system (TMS) migration is a significant undertaking that teams pursue for compelling business reasons. Common migration drivers include cost optimization—current platform pricing has become prohibitive as your project scales or you've outgrown a free tier. Feature gaps force migration when critical capabilities like over-the-air updates, advanced workflows, or specific integrations aren't available in your current platform. Performance and reliability issues such as slow response times, frequent outages, or inability to handle your translation volume push teams to seek better infrastructure. Vendor dissatisfaction around poor support, uncertain roadmap, or acquisition by company with misaligned priorities motivates platform changes. Technical requirements like specific API capabilities, SSO integration, compliance certifications, or self-hosting needs may require a different platform.

Whatever your motivation, successful TMS migration requires careful planning, systematic data export, format transformation, thorough testing, and coordinated team training. Rushed migrations risk data loss, translation corruption, workflow disruption, and translator frustration. This guide provides a proven framework for switching platforms while preserving translation quality and minimizing downtime.

Pre-Migration Planning Checklist

1. Audit Current TMS Usage

Projects and Keys: Document total number of projects, translation keys per project, and languages per project. Identify which projects are active vs. archived.

TerminalCopy
1# Example: Count keys per project
2Project A: 2,450 keys × 12 languages = 29,400 translations
3Project B: 890 keys × 6 languages = 5,340 translations
4Project C (archived): 3,200 keys × 8 languages = 25,600 translations
5Total: 6,540 keys, 60,340 translations

Active Users: Count translators, reviewers, developers, and managers. Map roles to new platform permissions model.

Translation Memory Size: Export TM and check total translation units. Large TMs (100k+ units) may require special import procedures.

Glossaries: Document number of glossary terms per language. Identify organization-wide vs. project-specific glossaries.

Integrations: List all active integrations: Git repos, CI/CD pipelines, Slack/Discord notifications, webhooks, API consumers. Assess which must be recreated vs. deprecated.

File Formats: Document formats currently in use (JSON, YAML, PO, XLIFF, Android XML, iOS strings). Verify new platform supports them.

2. Define Success Criteria

Data Completeness:

• 100% of active project keys and translations migrated
• Translation memory preserved with match accuracy ≥ 95%
• Glossaries imported with all metadata intact

Timeline:

• Migration completion date
• Acceptable downtime window (if any)
• Training completion deadline

Quality:

• No corrupted characters or encoding issues
• Placeholder variables preserved correctly
• Formatting (bold, italics, line breaks) maintained

Team Readiness:

• All users trained on new platform
• Documentation updated
• Support escalation path established

3. Choose Migration Approach

Big Bang Migration: Switch all projects at once during coordinated cutover window.

Pros: Single transition, clear cutoff date, consistent experience across projects. Cons: Higher risk, requires more extensive testing, larger downtime window. Best for: Small organizations (1-3 projects), teams with flexible deadlines.

Phased Migration: Move projects incrementally, starting with low-risk projects or new projects.

Pros: Reduced risk, learn from early phases, smaller testing scope per phase. Cons: Maintaining two platforms temporarily, potential confusion about which platform to use. Best for: Large organizations (5+ projects), risk-averse teams, ongoing active translation.

Hybrid Migration: New projects start on new platform, existing projects migrate when convenient (during maintenance periods or major updates).

Pros: Minimal disruption to active work, natural transition timeline. Cons: Longest dual-platform period, translation memory split across systems. Best for: Continuous translation workflows, teams with limited migration resources.

Data Export Strategies

Exporting Translation Keys and Values

JSON/YAML Export: Most platforms support exporting translations in JSON or YAML format per language.

Example Export Structure:

JSONCopy
1{
2  "project": "web-app",
3  "language": "es",
4  "keys": [
5    {
6      "key": "auth.login.title",
7      "value": "Inicia sesión en tu cuenta",
8      "context": "Login page title",
9      "tags": ["auth", "ui"]
10    },
11    {
12      "key": "auth.login.submit",
13      "value": "Iniciar sesión",
14      "context": "Login button text"
15    }
16  ]
17}

Validation: After export, verify key count matches expected totals. Check random samples for data integrity.

TerminalCopy
1# Verify export completeness
2jq '.keys | length' export-es.json
3# Expected: 2450 keys
4
5# Check for null/empty values
6jq '.keys[] | select(.value == null or .value == "")' export-es.json

XLIFF Export: For platforms supporting XLIFF (XML Localization Interchange File Format), export to XLIFF for maximum metadata preservation.

Example XLIFF:

XMLCopy
1<xliff version="1.2">
2  <file source-language="en" target-language="es" datatype="plaintext">
3    <body>
4      <trans-unit id="auth.login.title">
5        <source>Sign in to your account</source>
6        <target>Inicia sesión en tu cuenta</target>
7        <note>Login page title</note>
8      </trans-unit>
9    </body>
10  </file>
11</xliff>

CSV Export (Fallback): If structured formats unavailable, export to CSV. Be cautious with special characters and encoding.

CSVCopy
key,language,value,context
auth.login.title,es,Inicia sesión en tu cuenta,Login page title
auth.login.submit,es,Iniciar sesión,Login button text

Exporting Translation Memory

TMX Format (Standard): Export translation memory to TMX (Translation Memory eXchange) format for universal compatibility.

XMLCopy
1<tmx version="1.4">
2  <header srclang="en" creationtool="PlatformName" />
3  <body>
4    <tu tuid="1">
5      <tuv xml:lang="en">
6        <seg>Welcome to our platform</seg>
7      </tuv>
8      <tuv xml:lang="es">
9        <seg>Bienvenido a nuestra plataforma</seg>
10      </tuv>
11    </tu>
12  </body>
13</tmx>

Validation: Check TM unit count and spot-check quality of exported units.

TerminalCopy
1# Count TM units in TMX file
2grep -c '<tu' translation-memory.tmx
3
4# Extract sample units for review
5xmllint --xpath '//tu[position()<=10]' translation-memory.tmx

Platform-Specific Formats: Some platforms export TM in proprietary formats. If possible, convert to TMX using platform tools or request TMX export from support.

Exporting Glossaries

TBX Format (Standard): Export glossaries to TBX (TermBase eXchange) for maximum compatibility.

XMLCopy
1<martif type="TBX">
2  <text>
3    <body>
4      <termEntry id="term1">
5        <langSet xml:lang="en">
6          <tig>
7            <term>dashboard</term>
8          </tig>
9        </langSet>
10        <langSet xml:lang="es">
11          <tig>
12            <term>panel de control</term>
13          </tig>
14        </langSet>
15      </termEntry>
16    </body>
17  </text>
18</martif>

CSV Alternative: Export glossaries to CSV if TBX unavailable.

CSVCopy
term_en,term_es,term_fr,definition,notes
dashboard,panel de control,tableau de bord,Main metrics screen,Preferred term for UI

Format Conversion and Transformation

Common Conversion Scenarios

Scenario 1: Nested JSON to Flat Keys

Source (Nested JSON from old platform):

JSONCopy
1{
2  "auth": {
3    "login": {
4      "title": "Sign in",
5      "email": "Email"
6    }
7  }
8}

Target (Flat keys for new platform):

JSONCopy
1{
2  "auth.login.title": "Sign in",
3  "auth.login.email": "Email"
4}

Conversion Script:

JavaScriptCopy
1function flattenJSON(obj, prefix = '') {
2  const flattened = {};
3
4  Object.keys(obj).forEach(key => {
5    const fullKey = prefix ? `${prefix}.${key}` : key;
6
7    if (typeof obj[key] === 'object' && obj[key] !== null) {
8      Object.assign(flattened, flattenJSON(obj[key], fullKey));
9    } else {
10      flattened[fullKey] = obj[key];
11    }
12  });
13
14  return flattened;
15}
16
17const nested = require('./export-nested.json');
18const flat = flattenJSON(nested);
19fs.writeFileSync('./import-flat.json', JSON.stringify(flat, null, 2));

Scenario 2: CSV to JSON

Source (CSV export):

CSVCopy
key,es,fr,de
auth.login.title,Iniciar sesión,Se connecter,Anmelden
auth.login.email,Correo,Email,E-Mail

Target (JSON per language):

JSONCopy
1// es.json
2{
3  "auth.login.title": "Iniciar sesión",
4  "auth.login.email": "Correo"
5}

Conversion Script:

JavaScriptCopy
1const csv = require('csvtojson');
2
3csv().fromFile('./export.csv').then(rows => {
4  const languages = Object.keys(rows[0]).filter(k => k !== 'key');
5
6  languages.forEach(lang => {
7    const translations = {};
8    rows.forEach(row => {
9      translations[row.key] = row[lang];
10    });
11
12    fs.writeFileSync(`./${lang}.json`, JSON.stringify(translations, null, 2));
13  });
14});

Scenario 3: Preserving Placeholders

Different platforms use different placeholder syntaxes:

• Lokalise: {{variable}}
• Crowdin: %variable%
• IntlPull/i18next: {{variable}}
• ICU MessageFormat: {variable}

Conversion:

JavaScriptCopy
1function convertPlaceholders(text, fromFormat, toFormat) {
2  const patterns = {
3    lokalise: /\{\{(\w+)\}\}/g,
4    crowdin: /%(w+)%/g,
5    icu: /\{(\w+)\}/g
6  };
7
8  const replacements = {
9    lokalise: '{{$1}}',
10    crowdin: '%$1%',
11    icu: '{$1}'
12  };
13
14  return text.replace(patterns[fromFormat], replacements[toFormat]);
15}
16
17// Example: Convert Crowdin to ICU format
18const crowdinText = "Welcome %name%, you have %count% messages";
19const icuText = convertPlaceholders(crowdinText, 'crowdin', 'icu');
20// Result: "Welcome {name}, you have {count} messages"

Encoding and Character Set Issues

Problem: Exported files contain corrupted characters (é → é, ñ → ñ).

Cause: Encoding mismatch. Export was UTF-8 but opened as Latin-1, or vice versa.

Solution: Verify and force UTF-8 encoding.

TerminalCopy
1# Check file encoding
2file -I export.json
3# Output: export.json: application/json; charset=utf-8
4
5# Convert to UTF-8 if needed
6iconv -f ISO-8859-1 -t UTF-8 export.json > export-utf8.json

Prevention: Always specify UTF-8 when exporting and importing. Validate special characters after conversion.

Preserving Translation Memory and Glossaries

Translation Memory Migration

Step 1: Export TM from Old Platform

Export in TMX format if available. If not, export translation pairs and convert to TMX.

Step 2: Clean TM Before Migration

Remove low-quality entries, outdated translations, and duplicates.

JavaScriptCopy
1function cleanTM(tmUnits) {
2  return tmUnits.filter(unit => {
3    // Remove units with empty translations
4    if (!unit.target || unit.target.trim() === '') return false;
5
6    // Remove units where source === target (likely errors)
7    if (unit.source === unit.target) return false;
8
9    // Remove very short units (< 3 chars, likely noise)
10    if (unit.source.length < 3) return false;
11
12    return true;
13  });
14}

Step 3: Import to New Platform

Upload TMX file via new platform's import tool. Monitor import progress and error logs.

Step 4: Validate Import

Compare TM unit counts and test match quality.

Old platform TM: 45,820 units
Imported TM: 45,203 units
Difference: 617 units (likely duplicates or invalid entries removed)

Test fuzzy matching with sample sentences to verify match percentages align with expectations.

Glossary Migration

Step 1: Export Glossary

Export to TBX or CSV with all metadata (definitions, prohibited terms, context).

Step 2: Review and Update

Migration is opportunity to review terminology. Update outdated terms, add missing definitions, and remove obsolete entries.

Step 3: Transform Format

Map exported glossary structure to new platform's import format.

Example Mapping:

Old Platform CSV:
term,language,translation,note

New Platform JSON:
{
  "term": "...",
  "translations": { "es": "...", "fr": "..." },
  "definition": "...",
  "notes": "..."
}

Step 4: Import and Validate

Import glossary, then spot-check terms in translation interface to verify they appear correctly with all metadata.

Testing After Migration

Data Integrity Testing

Key Count Verification:

TerminalCopy
1# Compare key counts per language
2Old Platform - Spanish: 2,450 keys
3New Platform - Spanish: 2,450 keys ✓
4
5Old Platform - French: 2,398 keys
6New Platform - French: 2,398 keys ✓

Random Sample Validation: Select 50-100 random keys and manually compare translations between old and new platform.

Special Character Testing: Check keys containing special characters, emojis, HTML entities, and non-Latin scripts.

Key: product.emoji
Old: "🎉 Congratulations! 🎉"
New: "🎉 Congratulations! 🎉" ✓

Key: legal.copyright
Old: "© 2026 Company"
New: "© 2026 Company" ✓

Placeholder Verification: Test keys with variables, pluralization, and formatting.

Key: messages.count
Old: "You have {count} new messages"
New: "You have {count} new messages" ✓

Functional Testing

Translation Workflow:

• Create test project
• Add new translation keys
• Assign to translator
• Submit translations
• Review and approve
• Export to verify format

Integration Testing:

• Test API authentication
• Fetch translations via API
• Update translations via API
• Verify webhook delivery
• Test Git sync (if applicable)

Performance Testing:

• Import large translation file (1000+ keys)
• Search for keys with various filters
• Export large project
• Measure response times

User Acceptance Testing (UAT)

Translator Testing: Select 2-3 translators to test translation interface with real content.

Checklist:

• Can find assigned translation tasks
• Translation editor is intuitive
• Glossary terms appear correctly
• Translation memory suggestions work
• Can save and submit translations
• No confusing UI elements

Developer Testing: Developers test integration with codebase.

Checklist:

• API keys work in development environment
• Translation files export in expected format
• CI/CD pipeline integrates successfully
• Webhook events trigger as expected
• Local development workflow unchanged

Common Migration Pitfalls

Pitfall 1: Incomplete Data Export

Symptom: Missing translations discovered after migration is complete.

Cause: Export didn't include archived projects, disabled keys, or specific branches.

Prevention: Export all data including archived content. Verify total key counts before proceeding.

Pitfall 2: Encoding Corruption

Symptom: Special characters display incorrectly after migration.

Cause: Encoding mismatch during export/import cycle.

Prevention: Enforce UTF-8 throughout process. Validate special characters immediately after each step.

Pitfall 3: Lost Metadata

Symptom: Context notes, tags, descriptions missing in new platform.

Cause: Export format doesn't support metadata, or import process doesn't map metadata fields.

Prevention: Use XLIFF or platform-specific formats that preserve metadata. Test import with small dataset first.

Pitfall 4: Broken Integrations

Symptom: CI/CD pipeline fails, webhooks don't fire, API calls return errors.

Cause: Different API structure or authentication in new platform.

Prevention: Document all integrations pre-migration. Test each integration in staging before production cutover.

Pitfall 5: Inadequate Training

Symptom: Translators confused, asking basic questions, making errors due to unfamiliarity.

Cause: Insufficient training or documentation for new platform.

Prevention: Conduct live training sessions, create video tutorials, and provide written guides. Allow practice period before full migration.

Pitfall 6: No Rollback Plan

Symptom: Critical issue discovered post-migration with no way to revert.

Cause: Old platform deactivated immediately after migration.

Prevention: Maintain old platform in read-only mode for 30 days post-migration. Keep full data backups.

Downtime Planning and Communication

Minimizing Downtime

Read-Only Period: Before cutover, set old platform to read-only mode. This prevents new translations during migration window while allowing reference access.

Parallel Operation: If possible, run both platforms briefly. New content goes to new platform, ongoing work finishes on old platform.

Phased Cutover: Move projects during low-activity periods (weekends, holidays). Stagger cutover across time zones.

Communication Plan

Pre-Migration (2 weeks before):

• Announce migration date and expected downtime
• Provide training schedule
• Share new platform documentation

Migration Week:

• Daily updates on migration progress
• Known issues and workarounds
• Contact info for support during transition

Post-Migration:

• Confirmation of successful migration
• Office hours for questions
• Feedback survey

Sample Communication:

Subject: Translation Platform Migration - Action Required

Team,

We're migrating from [Old Platform] to IntlPull on [Date].

What you need to do:
1. Complete all in-progress translations by [Date - 3 days]
2. Attend training session: [Link to calendar invite]
3. Test new platform in staging: [Staging URL]

Timeline:
- Feb 15: Old platform read-only mode enabled
- Feb 16-17: Migration weekend
- Feb 18: New platform live, training sessions
- Feb 19: Old platform deactivated

Questions? Reply to this email or join office hours [Link].

Thanks,
Localization Team

Platform-Specific Migration Guides

Migrating from Lokalise

Export Process:

1. Navigate to Project Settings → Export
2. Select all languages
3. Choose JSON or XLIFF format
4. Download translations

Export TM: Settings → Translation Memory → Export TMX

Export Glossary: Glossary → Export CSV

Gotchas:

• Lokalise uses {{variable}} placeholders
• Tags export requires special permissions
• Screenshots don't export with standard export (manual download needed)

Migrating from Crowdin

Export Process:

1. Project → Settings → Export
2. Select file format (JSON, XLIFF, CSV)
3. Download translations per language

Export TM: Project → Translation Memory → Export TMX

Export Glossary: Project → Glossary → Export TBX or CSV

Gotchas:

• Crowdin uses %variable% placeholders (convert to target format)
• Context stored separately from translations
• Branch-based translations need per-branch export

Migrating from Phrase

Export Process:

1. Project → Download
2. Select locale and format
3. Configure export settings (include tags, descriptions)

Export TM: Project → Translation Memory → Export TMX

Export Glossary: Account → Glossaries → Export TBX

Gotchas:

• Phrase supports multiple file formats per project
• Order matters for key organization
• Verify plural form handling during export

IntlPull Migration Support

Migrating to IntlPull is streamlined with dedicated migration tools and support to minimize risk and downtime.

Automated Import Tools

Platform-Specific Importers: IntlPull provides import tools for popular platforms (Lokalise, Crowdin, Phrase). Upload your export files, and IntlPull automatically maps formats, preserves metadata, and imports translations with full fidelity.

Migration Assistance

White-Glove Migration Service: For enterprise customers, IntlPull offers assisted migration where our team handles data export, transformation, import, and validation. You provide credentials to old platform; we deliver fully migrated IntlPull instance.

Parallel Testing Environment

Test migration in IntlPull staging environment before committing. Import data, test workflows, train team, validate integrations—all without affecting production systems.

Flexible Import Formats

IntlPull supports JSON, YAML, PO, XLIFF, CSV, TMX, TBX, Android XML, iOS strings, and more. No complex transformation scripts required for standard formats.

TM and Glossary Preservation

Import TMX and TBX files directly. IntlPull preserves match metadata, translator info, and all custom fields. Test TM match quality immediately after import to verify accuracy.

Rollback Protection

IntlPull maintains version history for all imports. If migration issue discovered, rollback to previous state without data loss.

By providing comprehensive migration support, IntlPull reduces the friction and risk typically associated with platform switches.

Frequently Asked Questions

How long does a typical TMS migration take?

Small projects (1-2 projects, 1000 keys): 1-2 weeks including planning and testing. Medium organizations (5-10 projects, 5000 keys): 4-6 weeks for phased migration. Large enterprises (20+ projects, 50,000+ keys): 2-3 months for comprehensive migration with extensive testing. Actual migration/import typically takes hours to days; majority of time is planning, testing, and training.

Can I keep using my old platform during migration?

Yes, for phased migration. Set old platform to read-only mode during final cutover to prevent translation drift. For big bang migration, schedule downtime window (typically 24-48 hours) where no translation work occurs. Communicate timeline clearly to avoid lost work.

What if some translations don't migrate correctly?

Validate migrations with test imports before full migration. If issues discovered post-migration, identify affected keys, re-export from old platform (kept in read-only mode), and re-import specific problematic content. Maintain old platform access for 30 days post-migration as safety net.

Do I need to retrain all translators?

Yes, conduct training sessions on new platform. Most translators adapt quickly (1-2 hours training sufficient for basic proficiency). Provide documentation, video tutorials, and office hours for questions. Consider overlap period where old platform remains accessible as reference.

How do I migrate integrations like Git sync and webhooks?

Document all current integrations before migration. Recreate in new platform using new API endpoints and authentication. Test thoroughly in staging environment. Update CI/CD configurations, webhook URLs, and API keys in your codebase. Plan integration cutover separately from data migration if possible.

Should I clean up translations before migrating?

Yes, migration is ideal opportunity for housekeeping. Remove obsolete keys, archive inactive projects, update glossary, clean translation memory. Migrating clean data is faster and improves new platform performance. However, don't block migration on achieving perfect data—migrate what exists, clean incrementally post-migration.

What if my current platform doesn't support TMX/TBX export?

Contact platform support to request export assistance. Many platforms can generate TMX/TBX even if not exposed in UI. If impossible, export to CSV and use conversion scripts to generate TMX/TBX. IntlPull can import CSV directly and build TM from historical translations. Some data loss acceptable if TM will rebuild quickly through continued translation work.