Migrating from a legacy TMS to an AI execution layer: a 90-day playbook

Every VP of Localization who has tried to replace a TMS knows the real obstacle isn't the new platform, it's the fact that three product launches, a compliance filing, and a marketing campaign are already mid-flight inside the old one. Rip-and-replace sounds clean in a vendor pitch and reckless in a steering committee meeting. Nobody signs off on a cutover that stalls a launch, and no localization lead wants to be the reason a market date slips.

That's the wrong framing. You don't need to replace a TMS in one motion. You need a sequence that inventories what you actually have, proves the new execution layer on real work while the legacy system keeps running, and only then migrates volume, phase by phase, with a rollback path at every step. This playbook lays out that sequence over 90 days, using Ollang's SDK-based asset scanning, its local Asset Management control panel, and Kanban-based workflow to reduce risk without freezing active work.

Why phased beats big-bang

Legacy TMS platforms accumulate years of project structures, translation memories, glossaries, and vendor relationships that don't transfer cleanly to any new system. A hard cutover forces you to migrate all of that at once, under deadline pressure, with no fallback if something breaks mid-launch. A phased migration treats the new execution layer as something you run in parallel first, prove against real content, and expand only as confidence and coverage grow. The legacy TMS does not get switched off until the new system has demonstrably absorbed its workload, including the review discipline your legal, brand, and regional teams already trust.

Phase 1 (Days 1-15): Inventory before you migrate anything

You cannot plan a migration around content you haven't counted. Most localization teams underestimate their own footprint, the JSON and YAML string files sitting in five repos, the hardcoded UI strings nobody flagged, the video and audio assets scattered across marketing drives, the images with embedded text.

Start by installing the Ollang SDK and running it against your existing repositories and asset stores. The SDK scans i18n files (JSON, YAML), hardcoded strings, videos, images, and audio, which gives you a single inventory pass across content types that, in a legacy TMS, usually live in separate silos with separate export processes. Running the SDK is a single command, npx @ollang-dev/sdk start, which starts the Ollang Asset Management server, and the control panel opens automatically in your browser at http://localhost:5972.

Configuration is deliberately narrow at this stage: point the SDK at your project root, declare your source language and target languages, and decide whether video content should route to AI dubbing or subtitling by default. That configuration lives in a simple ollang.config.ts file, and the SDK Quick Start guide walks through the exact fields.

The output of Phase 1 isn't a translation, it's a map. You now know, file by file and asset by asset, what's in scope for migration, what format it's in, and what's currently untracked by your legacy TMS. That map is what makes every later phase estimable instead of speculative.

Phase 2 (Days 16-45): Run a pilot in parallel, not instead of

This is where most teams get nervous, and it's exactly where a phased approach earns its keep. You are not turning off the legacy TMS. You are running a bounded pilot, one product line, one document set, one video library, through Ollang's Asset Management control panel while the rest of your operation continues exactly as before.

Once assets are scanned, they land on a Kanban board inside the control panel. The interface scans i18n files, shows a Kanban board (Scanned → Translating → Translated → Submitted), sends selected items to Ollang for translation, and applies translations back to your codebase. Practically, this means your team selects a folder, scans the project, watches items populate the Scanned column, then selects items, chooses a target language, and moves them into translation, a visual, auditable progression that any localization ops lead can read at a glance without needing engineering to explain what's happening.

The pilot should deliberately include your hardest cases: a video that needs AI dubbing, a document with embedded formatting, a JSON file with nested keys. If your CMS content lives outside the codebase, for example a Strapi instance, the control panel supports capturing that too, since for CMS content you can add the Browser SDK to your site.

The goal of this phase is comparison, not conversion. You're running the same content class through both systems long enough to validate turnaround time, formatting fidelity, and terminology consistency before you commit a single high-volume workflow to the new layer.

Phase 3 (Days 46-70): Protect review continuity during cutover

The part of a TMS migration that breaks trust fastest is when a legal reviewer or a trusted external LSP suddenly loses visibility into what they're approving. If your compliance team has spent two years building confidence in a specific review chain, that chain needs to survive the migration intact, or the whole project gets treated as a quality risk regardless of how good the AI output is.

Ollang's execution layer is built to route around your existing review relationships rather than replace them outright. You can add a Level 1 review gate to any order to route output to Ollang-managed linguists or your own LSPs and editors, which means the pilot content from Phase 2 does not have to skip human review to prove itself, it can go through the same editors who already sign off on your legacy TMS output, just inside a different pipeline. Underneath that gate sits AI QC across accuracy, fluency, tone, and cultural fit, human QC annotations, QC score progression, and human-edit-percentage analytics, so you get a quantified view of how much your reviewers are actually changing, a number most legacy TMS setups never surface cleanly.

This phase is also where you formalize the operational model rather than improvise it. The platform's conceptual documentation describes a Folder → Project → Order hierarchy and an editor/LSP role structure that mirrors how agencies and internal review teams already operate, so mapping your existing review org onto the new structure is a configuration exercise, not a redesign. By the end of Phase 3, every reviewer who touched pilot content in the legacy TMS should have touched equivalent content in Ollang, with no drop in oversight and a QC trail that is more visible than before.

Phase 4 (Days 71-90): Move from manual orders to programmatic ones

Once the pilot has cleared review and your team trusts the output, the migration's real payoff shows up, not in the UI, but in what stops requiring the UI. High-volume, recurring content types, like release notes, product string updates, support articles, and structured documents, don't need a human clicking "translate" in a control panel every time a source file changes. They need to trigger localization automatically.

This is where you shift from the Kanban-driven pilot workflow to API- and webhook-driven order creation. Ollang's REST API supports programmatic uploads, orders, projects, revisions, QC, human review, and webhooks, all API-key authenticated, and for teams building AI-agent-driven pipelines, there's a hosted Model Context Protocol server (OAuth 2.0 + PKCE) that drops into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and similar platforms. In practice, this means your CI/CD pipeline or an internal agent can create an order the moment a string file changes, poll for status, and receive a webhook callback when translated output and QC scores are ready, with no manual project creation in the loop.

The full authentication model, request and response formats, and callback behavior are documented in the API reference, and the troubleshooting guide is worth reading before you wire up production webhooks, it covers requirements like ensuring your callback URL is publicly reachable, since internal hostnames and IPv6 destinations are blocked at the SSRF guard. Move your highest-volume, most repetitive content types first; keep lower-volume or judgment-heavy content, such as legal documents and brand campaigns, on manual order creation through the control panel for longer, since the operational cost of automating them is higher than the benefit.

By day 90, the legacy TMS should be handling a shrinking, well-defined set of content types, not because you forced a cutover, but because volume migrated to the execution layer as fast as validation allowed.

Risk checklist

Three risks sink most TMS migrations regardless of how good the receiving platform is. Address each explicitly before declaring any phase complete.

Glossary and TM migration. Legacy translation memories and glossaries represent years of terminology decisions. Ollang supports translation memories, custom instructions, folder- and project-level guidelines, but decisions about which legacy TM entries carry forward, which are stale, and which conflict with updated brand terminology need a human review pass, do not assume an automated import replaces that judgment call.

In-flight project handling. Never migrate a project mid-cycle. Let anything currently in review or delivery finish inside the legacy TMS, and route only new orders through Ollang. This is the single biggest reason to run Phases 1-3 in parallel rather than sequentially replacing systems.

Rollback plan. Every phase needs a defined point at which you can revert to the legacy TMS without losing work. Since review routing can change mid-order, review gates respect qcThreshold routing rules and orders may be re-routed automatically, and you can use Cancel Human Review to revert to the AI-only state and refund the review credits if priority changes, build your rollback checkpoints around order boundaries, not file boundaries, so a stalled migration never leaves a document half-translated in two systems at once.

The argument, restated

The case for a phased migration is that localization infrastructure only earns trust through demonstrated continuity, not through a vendor's feature list. A VP of Localization who can show, at day 90, that review quality held steady, no launch slipped, and volume moved to programmatic infrastructure on a measured schedule has built something durable: proof that the organization can operate localization as callable infrastructure rather than a fragile, manually-orchestrated service. That proof lets you keep expanding the execution layer's footprint next quarter without re-litigating the decision to migrate.