Why Translation Memory Matches Break After Migration

The units are still in the TM. You can open the editor and see last year's work. Concordance finds a distinctive phrase. And yet, after the move—new Studio version, memoQ import, Phrase project, TMX hand-off, server TM to file—the translation results pane is empty, or yesterday's 100% now scores 78%.

This is a different ticket from “a fuzzy I expected never appears.” That problem has its own diagnostic: what causes fuzzy matches to fail. After a migration, the usual cause is not a corrupt database. It is that lookup, index, language codes, segmentation, or penalties no longer describe the same object you exported.

This page is a post-migration checklist for LSP PMs and TM admins. It is not a vendor feature list.

What “we migrated the TM” usually means

Teams use “migration” for several jobs that break matches in different ways:

  • Tool upgrade. Same vendor, new TM index format. Trados file-based TMs from an older Studio release must be upgraded and reindexed before the current matcher will score them correctly.
  • CAT switch. memoQ, Trados, Phrase, or another tool via TMX (or a native import). Language codes, tags, and context rarely survive 1:1.
  • Server to file, or file to cloud. The project template still points at the old path. Translators search a leftover project TM.
  • Merge. Several TMs concatenated. Duplicates, conflicting targets, and “different TM” penalties then suppress the hit you wanted.

The units can be present in all four cases. Presence is not leverage.

Diagnostic: check these in ticket order

1. Confirm lookup is using the migrated TM

Open the project TM list. Hover the path. Check that the file you imported is marked for lookup (and for writing, if this is the working TM). Project templates and leftover local copies are a common miss: two TMs with the same display name, only one of them the migrated file.

Then concordance-search a phrase you know is unique to that TM. If concordance is empty, you are not searching the TM you migrated. If concordance finds the unit and segment lookup does not, the data arrived and the matcher or its index did not.

2. Check language pair and locale

Lookup is keyed on the project's source and target codes, not on “this looks like English.” A TM stored as en-US → de-DE will not serve en-GB → de-DE. The same failure happens when an import mapped zh-CN to zh, swapped source and target, or kept only the main language while the project asks for a sublanguage.

memoQ's TMX import is explicit that it normally matches main languages and can still import when sublanguages differ—but if you pick a language that is not in the project, those units do not come in. After a failed import, the editor looks fine because it shows what did load.

Fix: compare the language pair on the TM properties with the project pair, including locale. Do not “fix” this by creating a second TM and importing again until you know which pair you actually have.

3. Reindex or upgrade — an old index will hide fuzzy matches

File-based TMs keep the translation units in one structure and the lookup index in another. After a version change, a settings change, or an import, the index can be stale. The editor still lists every unit. Exact matches sometimes still work. Fuzzy lookup dies.

RWS documents this for Trados Studio: file-based TMs that have not been used in the current release, whose settings changed, or that were imported from an earlier Studio version must be upgraded. The upgrade backs up the file, reindexes it, and rebuilds fine-grained alignment. Studio marks those TMs with a warning triangle. Skipping the prompt is how a migrated TM “has everything” and returns nothing useful.

The same class of failure shows up in other tools when a full-text index is damaged or never built: exact (100%) lookup can continue while fuzzy lookup is empty, with no error in the UI. If the editor shows the unit and segment lookup does not, rebuild the index before you re-export.

4. Segmentation and tags changed with the destination tool

A TM stores the source as segmented at import. The new CAT applies its own segmentation rules and its own file filter. If the old tool broke at a semicolon and the new one does not, the live segment is no longer the stored segment. Edit-distance scores collapse even when every word is the same.

Inline tags do the same thing. TMX from Translator's Workbench, Studio, or memoQ encodes formatting differently. memoQ's import dialog has separate checkboxes for “Import memoQ formatting,” “Process TRADOS TMX,” and “Import as memoQ tag” for exactly this reason. Wrong boxes: the text is there, the tag stream is not, and a former 100% becomes a mid-fuzzy or a miss.

Fix: open one stored unit next to the live segment. Diff the sentence breaks and the inline codes. Align the project's segmentation rules with the TM's original import, or re-import the TMX with the tag options that match the files you are translating now.

5. Penalties and “faster lookup” hide hits that arrived intact

After a merge or a client hand-off, teams often attach the migrated TM with a penalty so translators do not trust it blindly. That is reasonable. It is also why a 100% disappears from the pane: the penalty pushed it below the minimum match value.

memoQ TM settings control match thresholds, tag strictness, and per-TM penalties. The same TM properties include a “more fuzzy hits” vs “faster lookup” slider. A TM created for exact/context leverage and slid toward faster lookup will return fewer fuzzy matches by design. If someone rebuilt the TM during migration and left that slider at the fast stop, you will think the import failed.

Check: temporarily clear the origin/alignment/format penalties and lower the threshold on one test file. If the units appear, the data migrated. Restore a modest penalty; do not leave the threshold at 40% in production.

6. TMX dropped the context that made 101% matches

Context matches (101% / 102%) need the previous/next segment or an ID stored with the unit. You cannot add that storage after the TM is created. memoQ says so in the import wizard: a no-context TM should not be the working or master TM, because later confirms cannot recover the context you did not store.

A TMX export is the usual way context dies. The segment text survives. The document name, context ID, and pickup fields often do not. After the move you still have 100% on identical sentences and you have lost the context matches that made leverage look healthy on the old system.

That is not a matching bug. It is a lossy interchange format. If you need context matches, migrate with the vendor's native format or recreate the TM with context storage before the import, then confirm a sample of units still return 101%.

What this usually is not

  • “The TM is corrupt.” Rare. Editor listing plus empty lookup is almost always index, language, or filters.
  • “We have to import it again to refresh matches.” A second import into a TM that allows multiple translations creates conflicting entries. Reindex first.
  • “Drop the threshold until something shows up.” That only un-hides noise. Find the setting that hid the real hit.
  • “The old TM was bad, so leverage is gone.” Quality and lookup are different problems. If concordance finds the unit, quality is a later audit.

Fixes that help — and fixes that do not

Help:

  • Attach the migrated file, not the leftover project TM from the template
  • Match locale codes, then reindex or run the vendor upgrade
  • Re-import TMX once, with the tag/formatting options for the source tool
  • Create the destination TM with context storage if you still need 101% matches
  • Clear temporary penalties on a test file before you declare the migration dead

Do not help, or help only once:

  • Importing the same TMX a second time “to be sure”
  • Merging every client TM into one file and hoping the matcher sorts it
  • Treating every missing 101% as a data-quality problem when TMX never stored context
  • Chasing individual fuzzy scores when the live file is segmented differently from the TM

The limit a migration cannot repair

A TM answers one question: have I stored a source string this close before? Moving the file does not teach the matcher meaning, audience, or why a translator chose a wording. After a clean migration you get the same string matcher on a new disk. That is why leverage can look “broken” even when every check above is green: the new source is a rewrite, or the stored translation was never right.

That is the same structural limit we described in Your Translation Memory Is Faithfully Preserving Your Mistakes: the database stores outputs, not the reasons those outputs were chosen.

That is why we built Aquilla around living memory instead of string lookup. Suggestions come from the project's own work, the surrounding context, and the team's documented translation philosophy—not from an edit-distance score against a segment pair that may or may not have survived a TMX round-trip. You can still run a conventional TM. This page exists because that workflow is real, and post-migration misses have mechanical causes.

Summary: post-migration match checklist

  • ☐ Confirm the migrated TM is attached for lookup (check the path, not just the name)
  • ☐ Concordance-search a distinctive phrase; if empty, you are in the wrong TM
  • ☐ Compare project vs TM language pair, including locale
  • ☐ Upgrade / reindex after a version change or import
  • ☐ Diff stored vs live segmentation and inline tags
  • ☐ Re-import TMX once with the correct source-tool tag options if codes drifted
  • ☐ Clear origin/alignment/format penalties on a test file
  • ☐ Check “faster lookup” vs “more fuzzy hits” if the TM was rebuilt
  • ☐ Treat lost 101% matches as missing context, not a corrupt file
  • ☐ If stored translations themselves conflict or look wrong, audit the TM rather than the scorer

Related Resources