How to migrate my projects from another localization platform to LingoHub

Teams that move localization work to a new platform already have resource files in a repository, years of approved translations, a glossary, connected tools, and a review process people follow. A localization platform migration moves those assets in a defined order and checks each one before the old platform is deprecated.

The effort depends on how many projects, file formats, integrations, and languages you have, and the sequence below applies at any size.

What a localization platform migration moves

Each category of data leaves the old platform and arrives in LingoHub differently.

Integrations and workflows, users, and roles carry no data across. They are rebuilt, which is why the process below documents them first.

How to migrate my projects from another localization platform

• Inventory your localization data and write a localization migration plan.

• Export from the current platform.

• Normalize file paths and language codes.

• Import projects into LingoHub.

• Migrate the glossary and the translation memory.

• Reconnect integrations.

• Rebuild workflows deliberately.

• Validate the migrated data.

• Plan the cutover.

Step 1: Create an inventory of your localization data

List every project on the current platform before exporting anything. For each one, record the resource file formats, the source and target languages, the repository and branch it syncs with, the size of the glossary and translation memory, the connected tools, and who reviews and approves translations. Archive abandoned projects instead of migrating them.

This is what your migration plan could look like:

Migrate a small, actively developed project first and leave the project with the most integrations for last.

Step 2: Export from the current platform

Whenever the old platform allows it, export the files in the format your application loads. A repository that stores de.json should come back as de.json. Interchange formats such as XLIFF 1.2 and CSV are useful for content that has no native file, such as strings managed only inside the old platform.

Export the glossary as CSV or TBX and the translation memory as TMX, even if you do not plan to import the TM directly. These exports are your record of the old platform’s state, and they make a rollback possible.

Check whether the export includes translation statuses; text alone cannot show which strings were approved.

Step 3: Normalize file paths and language codes

Language mapping needs a decision for every language. The old platform may export de_DE.json while your app loads de-DE.json, or it may write Chinese as zh-Hans while your repository uses zh-CN. When those names reach LingoHub unchanged, the import either creates a language you did not mean to add or does not match a file to its language.

LingoHub uses two-letter ISO 639-1 language codes, combined with a region code after a hyphen (en-US). Decide the mapping for every language before importing, and write it into the plan:

Old platform export            Repository convention
locales/de_DE.json         ->  locales/de-DE.json
locales/zh-Hans.json       ->  locales/zh-CN.json
res/values-fr/strings.xml  ->  res/values-fr/strings.xml

The Android row needs no change because Android’s resource directory names are their own convention. In LingoHub, the Files tab shows each path with a %{locale} language variable, and you can adjust that variable and the language code separator when a path does not match. For tag syntax, BCP 47 is the standard behind codes such as pt-BR and zh-Hant-TW, and the W3C guide to language tags explains how to choose between them.

Step 4: Import projects into LingoHub

LingoHub offers three ways to import projects, depending on your individual setup.

• File upload. Up to 20 files at once, or a single .zip file for a nested directory structure. LingoHub pre-selects the languages it detects in the uploaded files.

• API. The ZIP upload endpoint imports every file in an archive and detects languages from file names and paths. It suits teams migrating many projects with a script.

• Repository sync. Connect the repository and pull. This is the path for any project that will stay connected to Git, because the first pull and every later one go through the same settings.

Upload the target-language files along with the source files. LingoHub’s import settings have separate rules for source and target languages, covering whether an import creates new segments, updates existing ones (always, only empty ones, or never), and removes segments missing from the file. For a first import, letting target files create and update segments is what carries your existing translations across.

Set the status that imported translations receive before you import. Default statuses for new target segments, including approved, are configured under the project’s workflow settings. Without this, years of approved translations arrive as unreviewed work.

Step 5: Migrate the glossary and translation memory

Import the glossary before anyone translates in LingoHub. The glossary accepts CSV and TBX v3 files, as documented in the TBX import guide. An import replaces the current glossary rather than merging with it. Merge every glossary from the old platform into one file first, then import that file once.

The translation memory in LingoHub is built from the segments in your projects. The TM settings choose which projects feed it and which statuses are stored. Importing the translated target files in Step 4 is therefore also how you migrate translation memory for every string that is still in use. With the approved status included in the TM settings, approved translations become TM entries, and the TM finds exact or partial matches for new text from the first day.

A legacy TMX file is a different case: translations from retired products, or from content that none of your current files contain. LingoHub documents TM export as TMX and CSV, and importing a standalone TM like this is part of LingoHub’s migration support.

Step 6: Reconnect integrations

Integrations are rebuilt, so check each one against the inventory first: is it still used, which direction does it sync, and which branch does it target?

Disable the old platform’s sync on the same repository before enabling LingoHub’s. Two platforms pushing to one branch produce conflicting commits. The help article on automatic pull and push settings covers whether LingoHub pulls on a webhook or a schedule, and whether it opens a pull request or pushes directly. Our article on JSON-based content with Storyblok explains both Storyblok options, and the overview of how to localize content in a CMS covers file-based exports for other systems.

Step 7: Rebuild workflows deliberately

A workflow copied step by step from the old platform keeps the old platform’s limitations. Write down what each step achieves (a second reviewer for legal text, sign-off from the market owner for marketing copy), then build that outcome with LingoHub’s localization workflow: defined statuses, review before approval, and Git branches synced independently.

Roles are set at two levels. Workspace roles (Owner, Admin, Localization Manager, Member) control the account, and project roles (Admin, Localization Manager, Translator) control individual projects. Map each person from the old platform to one of them, instead of reproducing a custom permission scheme.

This is also the moment to decide where AI translation fits. LINA, LingoHub’s AI translation agent, drafts translations using your glossary and style guide, moves drafts to review for final approval, and writes approved corrections back into the translation memory.

Step 8: Validate the migrated data

Migration testing compares the new state with the old one, project by project.

• Key counts. Every language in LingoHub has the same number of keys as the source export.

• Translation coverage. The percentage translated per language matches the old platform within a few strings.

• Statuses. A sample of strings approved on the old platform is approved in LingoHub.

• Round trip. Export or push one language and diff it against the file in your repository. Differences should be limited to formatting you expected, such as key order.

• Placeholders. LingoHub’s quality checks flag mismatched placeholders and missing translations. A spike in either right after import usually points to an encoding or format setting.

• Glossary and TM. Translate a few new strings and confirm glossary terms are suggested and TM matches appear.

Record the results in the migration plan; they decide the cutover.

Step 9: Plan the cutover

The cutover is the moment translation work moves to LingoHub for a project. A parallel run before it, one or two release cycles where both platforms are available, keeps the old platform as a reference while the team confirms the new setup.

Freeze source-string changes for the cutover window, import anything translated since the first export, then switch the repository integration. Keep the old platform’s exports from Step 2 until the first release after the cutover ships, as a rollback point. Move projects one at a time in the order the plan defines.

Localization migration checklist

• [ ] Inventory every project: formats, languages, repositories, integrations, owners

• [ ] Archive projects that are no longer active

• [ ] Export files in native formats, plus glossary (CSV or TBX) and TM (TMX)

• [ ] Confirm the export includes translation statuses

• [ ] Map every language code and file path to the repository convention

• [ ] Set import rules and default statuses before the first import

• [ ] Import source and target files

• [ ] Merge glossaries and import once

• [ ] Disable the old sync, then connect the repository in LingoHub

• [ ] Map roles and rebuild review steps

• [ ] Validate key counts, coverage, statuses, round trip, and placeholders

• [ ] Run a parallel period, freeze, final import, cutover

• [ ] Keep the old exports until the first release after cutover

Migration support from LingoHub

LingoHub offers migration support. The LingoHub team helps you move projects, translation memories, and glossaries from your current platform, and connects the localization workflow to your development setup. Involve the team early when the migration includes a standalone translation memory with no matching files, dozens of projects or repositories, custom file formats outside LingoHub’s supported file types, or a contract end date that leaves little time for a parallel run.

Localization migration best practices

• Migrate the smallest active project first and treat it as a rehearsal.

• Decide the language mapping once, in writing, and apply it to every project.

• Import statuses with the translations; re-reviewing approved work is the most avoidable cost of a migration.

• Tell translators and reviewers the cutover date in advance, and where to find open work afterward.

FAQ

Can we keep our existing translations when we switch to LingoHub?

Yes. Import the target-language files along with the source files, and the existing translations become segments in LingoHub. Set the default import status so approved translations stay approved.

Do we lose our translation memory when we switch localization platforms?

The memory for every string still in your files is rebuilt from the imported translations. A separate legacy TM, covering content that no longer exists in files, is handled through LingoHub’s migration support.

How long does a localization migration take?

It depends on the number of projects, formats, and integrations. A single repository with standard formats can move within days; an organization with many projects should plan for one project per release cycle, including a parallel run.

Will our file structure still work?

LingoHub supports the common resource formats, including JSON, Android XML, Apple .strings and String Catalogs, XLIFF, Gettext PO, and Rails YAML. Once language codes are mapped, the directory structure in your repository can stay as it is.

Move your localization projects to LingoHub

A migration that follows a written plan, imports statuses with translations, and validates each project before cutover keeps localization work running while the platform underneath it changes. LingoHub connects translation files, repository updates, quality checks, and reviews in one place.

Want to test one project independently?

Start a 14-day free trial and try LingoHub with your own translation files. No credit card is required.

Start a free trial

Evaluating LingoHub for a larger organization?

Book a demo if your setup involves multiple teams, repositories, complex workflows, migration requirements, security reviews, or custom integrations.

Book a demo