From vendor portal to pipeline: a playbook for migrating enterprise localization into CI/CD without a rip-and-replace project

Most engineering leaders inherit localization the same way: a portal somewhere, a project manager who emails PDFs to a vendor, and a release process that pauses every time a string file needs translation. Nobody chose this system on purpose. It accreted, deal by deal, market by market, until "add a language" became a line item in the release calendar instead of a build step.

The instinct when this becomes unbearable is to buy a platform and migrate everything at once, content sources, review workflows, approval chains, vendor relationships, in a single cutover. That instinct is wrong, and it is the reason so many localization modernization projects stall for a year and then fail. The better path is staged: connect one content source to an execution layer, prove the pipeline model on that source, extend agent-driven access to one workflow, fold review into the same engine instead of routing around it, and only then widen scope. This is a sequencing problem rather than a platform-selection problem. What follows is the sequence.

Why the big-bang approach fails before it starts

A full-scale TMS migration typically asks an engineering org to do three hard things at once: change how content is sourced, change how quality is governed, and change how vendors get paid, all before anyone has evidence the new system works under production load. Each of those is a separate change-management problem with its own stakeholders, engineering, localization ops, legal, regional marketing, and stacking them means any single failure stalls the whole project. The staged approach isolates variables. You prove throughput before you touch governance, and you prove governance before you touch scope.

Stage 1: Pick one low-risk source and connect it directly

Start with a content source that is technical, bounded, and low political cost, such as a docs repo, an i18n string file set, or a single product's release notes. This is deliberately not the highest-visibility content in the company. The goal of Stage 1 is to answer one question: can content flow from our existing repo, through an execution layer, and back into our existing structure without a human manually shepherding files.

Ollang is a localization platform for video, audio, and document content, and it orchestrates dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, and exposes everything through APIs, an MCP server, an SDK, and agent Skills. For a Stage 1 pilot, the relevant surface is the API and SDK rather than the whole platform. The SDK scans and applies translations, and the API is used to build end-to-end localization pipelines. Concretely, that means your existing repo structure, your existing i18n file format, and your existing build step stay in place. The connector reads source strings, sends them through the execution layer, and returns translated files in the same structure they left in.

Formats in scope include DOCX, PDF, PPTX, XLSX, HTML, JSON, DITA, and mobile strings (.xml, .strings, .stringsdict), which matters because the pilot does not require a file-format migration on top of a workflow migration. If your i18n files are JSON today, they are JSON coming back.

The success criterion for Stage 1 is mechanical: did the pipeline run without a human opening a ticket. If the answer is yes for a few release cycles, you have earned the right to expand scope. If it is no, you have found the integration gap early, with one content type rather than five.

Stage 2: Introduce agent-driven access on one workflow

Once the API-based pipeline is stable, the next stage is not to connect more repos but to let an agent drive one workflow end to end. This is where MCP-style access matters, and it is worth being precise about why it differs from Stage 1's API connection.

An API integration is something your CI system calls on a schedule or on a webhook trigger, deterministic and scripted. MCP access lets an agent inside a developer's existing tool describe an outcome and have the execution layer carry it out, without the agent's operator hand-coding each API call. Native MCP/SKILLS integration lets agents like Claude Code, Cursor, Cline, Codex, Devin, Replit, and Lovable localize files directly from their workflow. The SKILLS layer is framework-agnostic; once connected to an agent, the agent can use Ollang capabilities on the fly, understanding the tech stack and workflow context to trigger the right multimodal localization actions.

Release-note localization is a good second-stage candidate because it is recurring, structurally simple, and low-ambiguity, and it currently causes real friction since release notes ship on a schedule engineering controls rather than one localization vendors control. Handing this workflow to an agent, "localize this release's notes into our supported markets and open a PR", tests whether agent-driven invocation holds up on production content without requiring a parallel governance rebuild yet. Handling structured file types like JSON directly within the workflow without breaking the structure, across many file and media formats, while keeping localization context-aware, is the specific technical bar this stage must clear.

Keep this stage scoped to one workflow. The temptation is to hand every repeatable task to agents once the first one works. Resist that; Stage 2's job is to prove the agent-access pattern, not to eliminate all manual localization work in one sprint.

Stage 3: Route review and approval through the same engine

This stage is where most migrations go wrong, because it touches people rather than pipelines. Up to this point, your existing review and approval habits, who signs off, what triggers escalation, which content requires native-speaker eyes, have remained untouched. Stage 3 asks whether those habits can run inside the execution layer instead of requiring a handoff to a separate legacy TMS for sign-off.

Developers integrate localization directly into applications and workflows, while business teams manage reviews, approvals, and publishing through a shared operational interface. Review runs inside the same pipeline that ingested the content and ran the AI-first pass, rather than in a separate system where content is exported and reimported. Content flows in, routes through review, and ships back automatically, without changing how your teams work.

This does not mean removing human review to speed things up. The model is to use AI to move faster while routing high-value or sensitive content through native-speaking review, domain expertise, approvals, and quality control. What changes is where that review happens, inside the same system that generated the draft, with full context, instead of as an export-review-reimport cycle against a disconnected TMS. Practically, this means defining which content classes trigger mandatory native-speaker review, such as legal, regulated, or high-visibility marketing material, and which can ship on AI-plus-spot-check, and configuring those rules once inside the pipeline rather than negotiating them per release with a vendor PM.

Stage 4: Expand to CMS, product, and support systems

Only after the pipeline model has held up on one content type, one agent workflow, and one governance model should you widen the aperture. The goal at this stage is to connect CMS, product, and support systems without rebuilding the workflows your teams already run. Because Stage 1 proved the connector pattern and Stage 3 proved the review pattern, expansion is mostly configuration, pointing the same execution layer at a new source and applying the review rules you already defined, not a new integration project.

This is also the stage where the modality range of the execution layer starts to matter operationally. Support content, product UI strings, and marketing pages have different structural formats and different risk profiles. The platform takes a source asset, such as a video, audio file, document, image, subtitle file, or strings file, and produces multilingual, fully reviewable outputs, including dubbed audio, mixed video, TTS-first flows, and captions exported to SRT, VTT, ASS, and broadcast-compatible formats. A CMS expansion may bring in video localization for product tours; a support-system expansion may bring in document localization for knowledge base articles. Because these run through the same execution layer and the same review configuration established in Stage 3, they do not require standing up parallel governance for each new modality.

Two failure modes that kill this migration

Migrating governance and automation at the same time. Teams that try to change how content is sourced and who approves it simultaneously end up debugging two systems at once when something goes wrong, and nobody can tell whether a bad translation slipped through because the pipeline misfired or because the new approval rule was misconfigured. Sequence them, pipeline first, governance second, even though it feels slower.

Skipping native-speaking review during cutover. The pressure during a migration is to prove speed, and the easiest way to look fast is to let AI output ship unreviewed for a sprint or two "just to test throughput." AI has made translation cheaper, but a translated string is not a localized product. Enterprise localization requires speed at scale, native-speaking quality, workflow control, and accountable sign-off, and cutting the quality leg out during the period when your teams are least familiar with the new system turns a pilot into a cautionary tale.

The argument, restated

The reason to sequence this migration rather than replace everything at once is that a staged rollout produces evidence at every step, and evidence is what gets budget for the next step. A CI/CD-integrated pipeline that has run cleanly on one docs repo for two release cycles is a stronger argument for expanding scope than any platform demo. An agent-driven release-note workflow that has not dropped a language variant in a quarter is a stronger argument for governance change than a policy memo. Enterprises do not fail at localization modernization because they picked the wrong execution layer; they fail because they tried to prove speed, quality, and governance simultaneously, with no checkpoint to catch which one broke. Treat this as infrastructure rollout rather than a vendor swap, and the sequence itself becomes the risk-management plan.