From ticket queue to API call: an implementation playbook for migrating off legacy TMS vendors

Your localization process likely works like this: someone files a ticket, a project manager scopes it, a vendor assigns linguists, files move through an FTP folder or a translation management portal, and three to twelve business days later a batch of translated strings lands back in your inbox for someone to manually merge into a release branch. Every ticket is a negotiation. Every release is gated by a human bottleneck outside your own systems.

This is an architecture problem, not a quality problem. Legacy TMS vendors and translation agencies were built around project-based engagements: you scope a job, route it to humans, and receive a file. That model made sense when translation required manual routing at every step. It does not make sense when your CI/CD pipeline ships code fifty times a day and your CMS publishes content continuously.

The playbook's argument is this: you don't need to rip out your CMS, your dev stack, or your existing team workflows to fix this. You need to route content through an execution layer instead of a ticket queue. Ollang sits alongside your existing systems, not replacing them, and turns localization from a service you request into an API call your pipeline makes automatically. What follows is a sequential migration path: audit, integrate, de-risk, and roll out in phases.

Phase 1: Audit before you integrate

Every migration failure we've seen in localization tooling starts the same way: a team wires up an API before it knows what's actually flowing through its current vendor relationship. Before touching any integration, map three things.

Content sources. List every system that currently generates content destined for translation, your CMS, your product's i18n string files, your docs platform, your marketing automation tool, your contract repository. Each source has a different extraction pattern: some export JSON or YAML string bundles, some export XLIFF, some are raw HTML or Markdown, some are PDFs or video files sitting in a DAM. Your current vendor already handles this extraction manually or semi-manually. That manual step is what an execution layer needs to absorb.

Dev platforms and delivery targets. Identify where translated content actually needs to land: production repos via pull request, a staging CMS, a CDN edge cache, a mobile app bundle, a customer-facing help center. Note the branch strategy, the deploy cadence, and who currently has merge authority on localized content. This becomes your integration map.

Current vendor touchpoints. Document every place a human currently intervenes, ticket creation, PM triage, translator assignment, review, delivery, QA sign-off. Each touchpoint is either a control you need to preserve (a legal reviewer sign-off, for instance) or a bottleneck you're migrating away from (a PM manually chasing a translator for a status update). Separating the two is the single most important output of the audit phase, because it tells you what to automate and what to keep as a governed checkpoint inside the new system.

Do this audit content type by content type, not all at once. A single, clearly scoped source, product UI strings, or a single documentation repo, is enough to move to Phase 2.

Phase 2: How content actually flows through the execution layer

Ollang is an operating layer, not a destination platform. Developers integrate localization directly into applications and workflows, while business teams manage reviews, approvals, and publishing through a shared operational interface. Operationally, this means your CMS stays your CMS and your repo stays your repo. What changes is what happens to content between "written" and "published."

Integration happens through four surfaces, depending on where the trigger lives. The platform orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows, and exposes APIs, an MCP server, an SDK, and agent Skills, giving you four integration methods.

For an engineering team migrating off a legacy vendor, the practical pattern looks like this:

• Source content lands in its normal home, a string file committed to a repo, a page published in the CMS, a document dropped in a shared drive, a video uploaded to a media library.
• A trigger fires, such as a commit, a webhook, a scheduled sync, or an agent invocation via MCP, and calls the Ollang API instead of opening a vendor ticket.
• Content routes through review according to rules you configure once: machine-first for low-risk UI strings, native-speaker review for customer-facing marketing copy, legal sign-off for regulated documents. Ollang provides a shared workflow that keeps every team aligned while maintaining visibility, quality control, and delivery speed across languages, and lets you control where native-speaking reviewers participate in the process.
• Translated content ships back automatically to the same delivery target the source came from, such as a pull request against your repo, a scheduled CMS publish, an updated video asset, or a refreshed help center article.

No one on your team files a ticket. No one manually re-uploads a translated ZIP file. The pipeline calls out, work happens, and the pipeline gets the result back in the shape it expects.

Where AI agents fit

If your engineering org is already using coding agents in the development loop, the migration path gets shorter. Native MCP/Skills integration lets agents such as Claude Code, Cursor, Cline, and Codex localize files directly from their workflow. Practically, an agent editing a codebase can detect new or changed strings, call Ollang's Skills to localize them in place, and commit the result without a developer manually exporting a string file. This is the same execution layer invoked from inside a different tool, not a replacement for the API-and-pipeline pattern above.

File-level handling that doesn't break your repo

A common failure mode in past localization automation attempts is string files that come back malformed, broken JSON, mangled placeholders, lost nesting. An execution layer must guarantee structural fidelity, especially for engineering-owned content. Handling JSON for i18n directly within the workflow without breaking placeholders or nesting is a baseline requirement for any pipeline integration your team will trust in production.

Phase 3: De-risking the migration

Three risks come up in nearly every legacy-to-pipeline migration. Address each explicitly before you scale beyond a pilot.

In-flight translation memory. Your existing vendor likely holds a translation memory (TM) built from years of prior work, approved phrasing, previously reviewed sentences, brand-specific constructions. Before you decommission that vendor relationship, export the TM in a standard exchange format and confirm it can be imported as reference context for your new pipeline. Losing this asset means every previously approved translation gets re-generated from scratch, which creates inconsistency your reviewers will immediately flag.

Terminology continuity. Product names, legal terms, and industry-specific vocabulary need to carry over exactly, not approximately. Build your glossary as a first-class artifact in the new system before the first production content flows through it. Terminology drift is the fastest way to erode trust in an automated pipeline among reviewers who are used to catching it manually.

Approval chain mapping. This is the risk engineering teams most often underestimate because it isn't a technical problem, it's an organizational one. Your legacy vendor relationship encoded an approval chain informally: a PM knew which languages needed legal review, which markets required marketing sign-off, which content types could ship without human review. That knowledge needs to become explicit, configured rules in the new system before you turn off the old one. Interview whoever currently owns vendor relationships and get their approval logic in writing before migration, not after something ships wrong.

Phase 4: Phased rollout

Don't migrate everything at once. Sequence the rollout in three stages.

Pilot on one content type. Pick something contained and low-political-risk, product UI strings or a single documentation set work well because the delivery target is clear and the review chain is simple. Run it end to end: source change triggers the pipeline, content routes through review, translated output ships back to the same repo or CMS. Measure cycle time against your old vendor baseline.

Expand modality. Once the pipeline pattern is proven for text, extend it to adjacent modalities relevant to your stack, for example software UI to marketing web pages, or documents to video subtitles and dubbing, using the same trigger-review-ship pattern rather than building a new integration from scratch for each modality.

Expand market. Add languages and markets last, not first. Each new market you add should reuse the same approval chain and terminology base you've already validated, rather than requiring a fresh negotiation the way a new market rollout would have under a ticket-based vendor.

The real argument for engineering leaders

Cost is not the main reason, although it often improves. Ticket-based vendor relationships put a human coordination layer between your release cadence and your global markets. Every ticket is a point where your shipping velocity gets throttled by someone else's queue. An execution layer does not remove human judgment from localization. Review, approval, and sign-off still happen, but it removes the coordination cost of routing every piece of content through a manual handoff.

The teams that get this right won't be the ones that bought the most features. They will be the teams that treated localization as infrastructure to integrate once, correctly, rather than a vendor relationship to manage forever.