The translation exit question nobody asks before signing

The question to ask before you sign

Before you sign with a translation vendor, ask one question: if we leave in two years, what exactly can we take with us?

Most buyers never ask it, because the purchase looks like a simple service: words go out, translations come back, priced per word. But something else builds up quietly in the background: every reviewed sentence, every agreed product term, every approval decision. And all of it lives inside the vendor's system, not yours.

That's what makes switching so hard. It's not the translation work itself, it's the years of accumulated decisions sitting in a format only they control. If you can't take that with you, your next vendor starts from zero, and you end up paying twice for work you already approved once.

So the real question isn't "how much per word." It's what you actually own when the contract ends: which assets, in which formats, with which decisions still attached to them.

Executive summary

Translation memory portability is the ability to move translation memory, termbases, style guides, and review decisions between systems while keeping their meaning intact. The short version:

• What you keep: reviewed segments, termbases, style guides, source files, and evaluation sets, provided your export rights are written into the agreement.
• What you lose: segment status, author, and domain tags, unless the export carries them, which sends approved segments back into review.
• What to require: TMX 1.4b (Translation Memory eXchange) for memory, TBX (ISO 30042) for termbases, and XLIFF 2.x for bilingual files. Also a fixed export fee and a post-termination window.
• How to test it: within 30 days, run a real export and import it into a tool you control. Score it on a 300 to 500 segment set.
• Why it matters at renewal: a low license price plus an expensive exit can cost more by year three. A tested exit on a higher license costs less.

The assets that actually move

Divide what you hold into two piles. Data includes translation memory, your termbase, the style guide, source files, and the evaluation sets used to judge quality. Configuration includes QA rule sets, integrations, user roles, dashboards, and prompts.

Data questions are about formats and metadata. Configuration questions are about rebuild effort, because configuration describes how your process runs inside one platform, including who approves what.

The split predicts the migration bill. Data usually moves with effort. Configuration usually moves with money and time, and some of it does not move at all.

Count the data and the configuration separately before signing, because only one of them leaves with you.

Two kinds of ownership: legal and technical

In practice, translation contracts often state that you own your data. That sentence is necessary and rarely sufficient. Legal ownership settles who holds the rights. Technical ownership settles whether you can exercise them.

Regulation does not settle this. GDPR covers personal data, and a translation memory is rarely personal data. The EU Data Act (Regulation (EU) 2023/2854, in application since 12 September 2025) covers data from connected products, which is a different asset class.

A compliant export can still arrive as a flat bilingual file with the metadata removed. Compliance gives you a right to ask, not a working export, so the format and the fee still belong in the contract.

GDPR, the EU Data Act, and confidentiality clauses do not guarantee that an export shows who approved what. That record belongs in the export metadata, not in a support conversation.

What an export preserves, and what it quietly drops

The standards exist, and they are specific. TMX 1.4b, the Translation Memory eXchange format, carries translation units as segment pairs with attributes such as creation date, author, and a status property. TBX (ISO 30042) carries a termbase with flags for preferred, forbidden, and case-sensitive terms. XLIFF 2.x carries bilingual documents with inline codes preserved. SRX 2.0 carries segmentation rules, which decide where sentences break. W3C ITS 2.0 carries metadata such as provenance and machine translation confidence.

Here is what a useful unit looks like.

<tu tuid="12345" creationdate="20250314T101500Z">
  <prop type="x-Status">translated</prop>
  <tuv xml:lang="en"><seg>Upload the signed agreement.</seg></tuv>
  <tuv xml:lang="de"><seg>Laden Sie die unterzeichnete Vereinbarung hoch.</seg></tuv>
</tu>

The x-Status property in a TMX file is a convention that tools write inside the standard <prop> element. TMX does not require it, so a technically valid file can arrive with no status information at all.

In practice, exports usually keep the segment pairs and drop the data around them. Status, author, and domain tags are commonly removed, so your team cannot tell whether a segment was approved, rejected, or never reviewed. A stripped export forces re-review even at high match rates, because the text matches and the history does not.

The same segment with and without metadata

Both files below are valid TMX. The stripped one imports as unreviewed text, so the receiving system cannot separate approved content from draft content. It also cannot prioritize what changed since the last delivery.

<tu tuid="12345" creationdate="20250314T101500Z" creationid="reviewer-07">
  <prop type="x-Status">approved</prop>
  <prop type="x-Domain">legal</prop>
  <tuv xml:lang="en"><seg>Upload the signed agreement.</seg></tuv>
  <tuv xml:lang="de"><seg>Laden Sie die unterzeichnete Vereinbarung hoch.</seg></tuv>
</tu>

<tu>
  <tuv xml:lang="en"><seg>Upload the signed agreement.</seg></tuv>
  <tuv xml:lang="de"><seg>Laden Sie die unterzeichnete Vereinbarung hoch.</seg></tuv>
</tu>

Termbases travel the same way

A TBX export is useful only when its flags survive the trip. Preferred, forbidden, and case-sensitivity settings decide how the new tool enforces a term, and a plain term list carries none of them.

<termEntry id="c1">
  <descrip type="subjectField">legal</descrip>
  <langSet xml:lang="en">
    <ntig>
      <termGrp>
        <term>signed agreement</term>
        <termNote type="termType">fullForm</termNote>
        <termNote type="administrativeStatus">preferredTerm-admn-sts</termNote>
      </termGrp>
    </ntig>
  </langSet>
</termEntry>

Two mechanical facts matter here. A TMX export is bilingual per language pair, so a project with ten target languages produces ten separate files to check. And exports rarely carry document context, so a 100% match can still be wrong in a new passage.

Segmentation adds a quieter problem. One English sentence may enter the old tool as a single segment, while the new tool splits it into two. A pair that returned a 100% match now returns as two partial matches. The words have not changed, the leverage has, and the difference is paid in reviewer time.

Four exits, four different losses

Each exit removes a different part of the stack, so a single checklist will not cover all four.

Agency to in-house or to a SaaS tool

Your organization usually holds the source files, so those survive. Reviewed segments survive only if the agency delivers a complete TMX export with metadata. Termbase, style guide, and review history often stay behind.

One SaaS tool to another

Both sides speak the same standards, so format is rarely the problem. Metadata and segmentation are. Import rules differ, so segment boundaries shift and match rates drop.

Integrations are rebuilt on top of that. A repository calls the old API from a CI job on merge, and a webhook pushes finished files into a CMS. Both rely on endpoints, identifiers, and payload shapes from the old platform, so each needs rebuilding and retesting before delivery works again.

Switching AI model inside the same platform

This exit gets overlooked because the platform stays the same. Platform assets survive: memory, termbase, users, project history. Model-adjacent assets do not: prompts, tuned parameters, and the quality comparisons that reset with the model.

The same termbase is loaded into the new system, yet behavior differs. One model enforces a forbidden term while another uses it anyway, even though the memory and termbase are unchanged. What moved is the behavior that applied them, so re-run evaluation sets before a model switch ships.

Vendor failure or acquisition

The worst case here is access, not quality. Notice periods decide how much you retrieve before systems change hands. Continuous delivery and escrow turn a hostile exit into a routine one.

If the vendor disappears, the only assets you keep are the ones you already exported.

The migration bill nobody quotes

Exits generate line items that never appeared in the original proposal. The export fee may be fixed or billed per word. Re-import consumes engineering hours. Segmentation mismatch lowers match rates and widens the review scope.

Re-review is usually the largest recurring cost, because it is paid in reviewer hours. Integration and webhook rebuild adds another engineering pass. Lost leverage shows up at renewal, because competing bids cannot use a memory that sits inside one vendor's walls.

Consider a round, illustrative example, not a benchmark. Suppose the memory holds 120,000 segments and you are moving six target languages. If 8 percent of segments drop out of the 100% match band into the 85-94 percent band, that equals 57,600 segment-language pairs. At two minutes of review per segment, the work reaches about 1,920 reviewer hours. Replace these numbers with the results from your own pilot export. The multiplier follows your segment count, not the license price.

Ask for each line item in writing before you commit. A vendor that cannot name the fee is unlikely to cap it.

The comparison that matters is not license price against license price. It is total cost across the contract life. A cheap license plus an expensive exit can cost more by year three than a higher license with a clean, tested exit.

Making portability testable

Run one drill in the first 30 days of a pilot. Ask for a real export of a live project, not a sample built for the demo, and import it into an independent tool your team controls.

Measure match-rate retention on a reference set of 300 to 500 segments. Publish the distribution before and after the import: 100%, 95-99%, 85-94%, and below 85%. If the 100% and 95-99% buckets shrink, the difference is reviewer work you will absorb later.

Give the drill an owner and a deadline during the pilot. Record the export time, the format, and whether the export needed a support ticket.

The email that gets a written answer

Written answers are easier to compare across vendors than verbal ones. The five-line template below is enough to start.

Subject: Export and portability terms before we proceed

1. Which export formats do you support for translation memory, termbases, and bilingual files, and at what cost?
2. Does the export include segment status, author, date, and domain tags?
3. Can we export on demand through the interface or API, or only on request, and within what time?
4. How long after termination does the export window stay open?
5. Will you run a test export of a live project during the pilot so we can measure match-rate retention in our own tool?

How TextUnited keeps those assets yours

The exit questions are easier to answer when terminology, translation memory, style guides, review decisions, and quality signals live in the client's own account instead of a vendor's project folder. This is how TextUnited is built. Approved decisions belong to the client, and they stay available after a project closes.

Approved state travels with the content. When a term is agreed, the same approved label is enforced wherever the work happens, in the interface, through the API, and through the MCP server that connects an AI assistant. Access is scoped with personal access tokens, so a read-only connection can look up terminology without gaining write access.

Portability is part of the product rather than a promise made on a call. Terminology and memory export in TBX, CSV, and TMX, so changing supplier is a decision rather than a restart.

Run the export drill described earlier on your own content. Import the result into a tool you control, and check what actually arrived.

Before you sign: the exit questions

Bring these questions to the next vendor conversation and ask for written answers.

1. Will you export our complete translation memory at our request, and in which standard format: TMX 1.4b or an agreed equivalent?
2. Does that export include per-segment metadata: status, author, date, and project or domain tags?
3. Is the export self-service through the UI or API, or a manual support ticket, and what is the turnaround commitment?
4. Can we export at any time during the contract, or only after termination, and how long does the post-termination window last?
5. Do we receive the full termbase, including preferred, forbidden, and case-sensitivity flags, rather than a plain term list?
6. Are custom machine translation models, prompts, and QA rule sets exportable? If not, what happens to them at exit?
7. Will you confirm in writing that our translation memory is not used to train or improve your models and is not shared across customers, and is that the default or an opt-in?
8. Where is the data stored, which sub-processors handle it, who inside your company can read it, and what are the retention and deletion policies?
9. Will you provide a deletion certificate after termination, with a defined date?
10. Is the export fee fixed in the contract, or billed per word or per segment?
11. If you are acquired or wind down, what is the notice period, and is our data escrowed or continuously delivered?

What a good answer sounds like

Export format. Good answers name TMX 1.4b and any other formats included, at no extra cost. Weak answers say the export can be provided on request.

Segment metadata. Good answers list the fields, such as segment ID, languages, timestamps, translator, reviewer, and approval state. Weak answers say the standard fields.

Self-service export. Good answers let admins export memory, termbases, and QA settings from the dashboard. Weak answers route it through support.

Post-termination window and fee. Good answers give a number of days and a fixed fee. Weak answers offer to discuss handover later.

Termbase flags. Good answers confirm that TBX export keeps flags such as preferred and forbidden. Weak answers say standard terminology data is included.

Custom models, prompts, and QA rules. Good answers say exactly which files leave the platform. Weak answers say the settings live in the platform.

What this means for your next renewal

Renewal is a practical moment to close the gap. Request the same export drill, compare it with the prior year, and put the export terms into the contract you are about to sign.

Portability is a procurement test, not a promise. Treat the export drill as a renewal task, because leverage at renewal depends on the memory you actually hold.