Choosing a Translation Management System is a strategic decision rather than a feature comparison, and the most useful way to make it is to follow a framework built on the buyer side. Veronica Carioni is Senior Localisation Manager at Skyscanner, where she leads the localisation team and drives strategies that improve the language experience across 40 locales; she previously led localisation initiatives at Vistaprint, with extensive experience on the end-client side of localization technology. She teaches that framework in her TranslaStars course TMS Selection: Strategy, AI & Implementation, with a deliberately practical aim: to help you select complex technology without losing sight of human and linguistic needs.
The course describes its own method in one sentence: it follows the lifecycle of a TMS decision: understand needs, involve stakeholders, map requirements, shortlist vendors, inspect tools, negotiate, implement, and evaluate. Those stages sit inside the five blocks the course is built on: TMS basics, modern TMS capabilities and integrations, selecting a TMS, evaluating choosing and negotiating, and implementing and evolving a TMS. This guide follows the five blocks in her order, because the order is the argument: you cannot evaluate a market you have not defined, and you cannot negotiate a tool you have not mapped. Inside that framework, three questions get developed in full here, because they are the ones teams ask most often: the TMS migration checklist, the localization orchestration platform that connects the systems you already run, and the TMS implementation plan that gets a team actually using the tool it bought.
In This Article
The five blocks of TMS selection
The framework this guide follows, in the order the course teaches it
The course framework. The five blocks of TMS selection, in the order Veronica Carioni teaches them.
1. Block 1. TMS Basics
The first block sets the vocabulary the rest of the decision depends on, and it does so in three moves: what a TMS actually is, which types exist in the market, and what the system is expected to give back.
1.1. What a TMS Is
The course gives a definition worth taking literally, because it already contains the argument for buying one:
The definition. "A Translation Management System (TMS) can bring together multilingual content workflows by bringing together project management, translation assets, machine translation, AI, quality, collaboration, integrations, reporting, and billing." Veronica Carioni, course materials for TMS Selection: Strategy, AI & Implementation.
Note what the sentence puts first: orchestration of the workflow, not the translation memory. The course then splits the capabilities into the two halves a buyer has to keep apart. The first is project and process management: project management, workflow management, integrations, collaboration, and billing and invoicing. The second is language management, the CAT side of the tool: translation memory, glossaries, machine translation and quality. Keeping the two halves visible is what stops a purchase from being decided by whichever half the demo spent longer on.
1.2. Types of TMS: Cloud, On-Premise, Enterprise and Orchestration Layers
With the vocabulary set, the block moves to the market. The course names four shapes a localization programme can end up buying, and it is honest about what each one costs you, which is the part a vendor comparison usually leaves out.
| Type of TMS | What it is | What it gives you, and what it asks for |
|---|---|---|
| Cloud-based | Hosted and accessed online. | Ease of access, no installation, frequent and seamless updates. |
| On-premise | Installed and hosted locally on the organisation's servers. | Security and compliance, and full data control, in exchange for hard maintenance and updates. |
| Enterprise | Developed in-house. | Fully customised, but not localization-focused, and costly in time and resources. |
| Orchestration layer | Connects TMS, MT engines, LLMs, CMS and product systems. | Dynamic routing between AI and human, workflow automation, and quality-based decisioning. |
The fourth row is the one that changes the shape of a shortlist, and it returns in Block 2. An orchestration layer does not replace the TMS; it sits above it, and it exists because modern localization content does not live in one place.
Deciding which of those you are buying, before any vendor conversation, is the first honest sentence of the whole process. It also settles a question buyers raise late and expensively: whether the thing you need is a new TMS at all, or a layer that makes the systems you already own work together.
1.3. Core Benefits and Main Features
The course names eight core benefits, and it is worth treating the list as the honest shape of the business case: automation, interoperability, centralization, collaboration, quality, scale, speed and governance. A system that cannot be argued for in those terms is being bought for its interface.
The feature list behind those benefits arrives in two parts. The first covers the engine room: translation features (translation memory, glossary, machine translation, in-context translation), content management (uploading, storing and managing multiple formats), workflow and project management (defining translation stages, assigning tasks and deadlines, tracking progress), integrations and APIs (streamlining content import and export) and automated workflows (reducing manual effort on repetitive tasks). The second part covers the operations around the language work: vendor management, collaboration, QA with automated quality checks and version control, reporting and analytics, and billing and invoicing.
One line in the material should be kept next to that list, because it changes how you read every vendor's website: the course emphasises that TMS are moving from individual features towards end-to-end workflow automation and orchestration. The features matter, but the direction of travel is toward the workflow those features run inside, next to a fourth item that arrives with the same force: AI orchestration, with dynamic routing between MT, LLM and human, quality-based decisioning through machine translation quality estimation, and workflow automation.
1.4. Are TMSs Becoming Obsolete?
The course asks the uncomfortable question directly, and it answers it in two columns rather than one verdict, which is the more useful format for a buyer.
| What is being questioned | What a TMS still delivers |
|---|---|
| Legacy architecture built around translation memories | It still powers the majority of hybrid workflows |
| Rigid, translation-focused workflows | It provides control over translation memories and term bases |
| Inefficiency caused by fragmentation in the localization tech stack | It centralises vendor collaboration |
| Rigid and complicated connectors | It provides version control |
| AI integrated superficially | It provides a secure data environment |
Read as a buyer, the left column is a list of questions to put in the requirements document, and the right column is the list of reasons a replacement has to be argued for rather than assumed. Neither column settles the purchase; together they describe what to test.
2. Block 2. Modern TMS Capabilities and Integrations
The second block is where the current market lives: what the system does beyond the translation memory, how it optimises the language assets it already holds, and how it connects to everything else.
2.1. AI-Powered Features in Today's TMSs
The course lists the AI capabilities buyers now see across vendors, and the list is a workable checklist for a demo: machine translation, including AI-powered MT with retrieval-augmented generation; translation engine selection, which dynamically chooses the best MT engine per content type or language; context-aware and adaptive suggestions; automated quality assurance, running grammar, style and terminology checks with severity; automated post-editing (APE), where AI improves translations and flags issues before human review; quality estimation (QE), which predicts quality and enables automated or selective human review; terminology management with AI, identifying key terms from source content and suggesting client-preferred terms; AI-driven workflow automation with smart routing and task assignment; sentiment and tone detection to maintain tone and brand voice; AI-powered rewriting to shorten, expand, summarise, rephrase or adjust tone; and source text optimization, which pre-edits the source for better MT results by simplifying, structuring or rephrasing complex input.
Two of those deserve a buyer's scepticism and a buyer's attention at the same time. Quality estimation and source text optimization are the ones that change your process rather than your throughput, because they decide what a human sees and when. Ask what happens when the estimation is wrong, and who owns the correction.
2.2. Augmented Translation and Translation Memory Optimisation
Alongside the headline features, the course covers the work done on the language assets themselves, which is where a mature programme recovers quality rather than speed. A TM threshold optimizer pinpoints the optimal threshold, based on previous analytics, that defines whether it is better to pre-translate using fuzzy matches or by using MT. Automated LQA runs with or without human validation, and augmented translations combine the two. TM clean-up automatically identifies and removes duplicates, corrects errors and updates outdated translations so that the assets stay accurate. Alongside them sit an AI-powered strings editor to optimise the copy, context-sensitive reviews, and automated glossary creation.
For a localization manager, this is the section that answers the question of what you are actually migrating. A TMS swap moves more than projects; it moves a memory and a term base that took years to reach their current quality, and a vendor that cannot describe how it will treat them is describing a fresh start.
2.3. Connectors, APIs and Orchestrators
Integrations get their own treatment, defined as the solutions that allow a TMS platform to connect and interact with other software systems. The course draws a clean line between the two classic options, and then adds a third to the list.
| Aspect | Connectors | API |
|---|---|---|
| What it is | Out-of-the-box solutions that let a TMS connect with specific third-party software | Interfaces that give different software a standardised way to communicate and exchange data |
| Development | No need for extensive custom development | Needs custom development |
| Reach | Only available for popular systems | Flexible enough to integrate with virtually any software |
| Cost | A fixed price paid once, unless customisations are needed | High development and maintenance costs |
The third option, named in the same breath, is the rise of orchestrators, which is where a localization orchestration platform becomes the right answer rather than a compromise. Modern localization rarely happens inside one tool: content is created in a CMS, stored in a repository, translated through a TMS, machine-translated or post-edited by an engine, checked by a QA system and reported in a dashboard. An orchestration layer connects those pieces, routes work between AI and human reviewers, and enforces the workflow across them, instead of asking a single TMS to become the centre of everything.
Orchestration above the tool
How a localization orchestration platform connects the systems a language team already runs
Orchestration above the tool. An orchestration platform sits above the TMS and the surrounding systems rather than replacing them, and its decisioning is what routes work between AI and human reviewers.
One commercial warning belongs with the diagram: the material flags the hidden costs in connectors, which is why the cost row in the table above is worth reading more carefully than the others. Before an integration is quoted as included, ask what it covers, what it excludes, and what happens when the connected system changes version.
2.4. Workflow Automation from Project Creation to Re-Import
The block closes with a five-stage workflow that shows what automation actually means in a TMS, stage by stage: project creation and setup, where project settings are pre-defined per content type or team; preparing content for translation, connected to other tools or repositories; assigning translators and deadlines and notifying them, with automated vendor and deadline assignment and automated notifications; translation and review, using translation memory and machine translation, context enriched through an LLM, and automated LQA; and finally re-import of the translated content, with automated import and notifications.
Workflow automation in five stages
Where automation and integrations sit in a TMS workflow
Workflow automation in five stages. The course example runs from project creation to re-import, with automation and integrations attached to each stage.
That sequence is also the most practical test in the whole framework. Walk your own workflow through the five stages and mark every step the system cannot automate, because those marks are the cost you will still be paying after the contract is signed.
3. Block 3. Selecting a TMS
The third block turns the knowledge into a method, and it starts with the buyer rather than the market. It is also where the lifecycle stages become concrete: understand the operation, involve the stakeholders, map the requirements, prioritise them, and only then approach vendors.
3.1. Understanding Your Content, Formats, Volumes and Budget
The course begins from what you actually have: content, formats, language pairs, workflows, integrations, storage, volumes, expertise, engineering support and budget. Each of those is a question a vendor will ask you anyway, and answering them first is what turns a demo into a comparison. The list is also a warning about the cheapest mistake in the process, which is describing a pilot-sized operation to a vendor and then living with a price based on a fraction of your real volume.
The material also offers a quick filter for whether the exercise is worth starting: the signals that a TMS is the right investment are a manual QA process, budget control needs, frequently updated content and large-scale translation projects. If none of those describe your operation, the honest answer may be that the tool is not yet the problem.
3.2. Involving Stakeholders and Capturing Their Use Cases
Requirements are then gathered from localization and from the cross-functional teams the system will touch, and the course is specific about capturing their use cases rather than their preferences. The distinction matters: a use case can be designed for, and a preference can only be argued about. Inviting those stakeholders early changes the shape of the shortlist: a developer who was consulted about a connector defends the choice after go-live, and a developer who meets the integration in production does not. The same holds for procurement, whose questions about terms, data processing and exit clauses arrive early if they are invited early, and very late if they are not.
The business case later depends on this step, which is why the course frames the impact analysis around the stakeholders the system will touch: developers and designers, product managers, marketers and copywriters. Each of them will ask what changes in their working day, and having an answer ready is what turns an approval into adoption.
3.3. Mapping Technical, Business and Functional Requirements
The next step is to map the requirements, and the course separates them into three categories, which is what stops three different arguments from collapsing into one.
| Requirement type | What it covers | Where it lands in the decision |
|---|---|---|
| Technical | Systems, connections, data storage and handling | The connectors, APIs and architecture discussion |
| Business | Support, compliance, contract and cost structure | The negotiation and the business case |
| Functional | What the tool does, day to day, for the people using it | The feature evaluation and the pilot |
3.4. Prioritising P0/P1/P2 and Must-Have vs Nice-to-Have
Once mapped, the requirements are prioritised as P0, P1 and P2, and separately as must-haves against nice-to-haves. This is the step that makes the rest of the process defensible, because it is the only one that forces the admission that some criteria are preferences rather than needs. A list where everything is a must-have cannot rank three vendors, and a scoring sheet built on it will quietly reward whichever demo came last.
The structure matters as much as the sorting. Mapping requirements across the three categories keeps the arguments apart, and it gives the eventual score sheet something to score. Review the prioritised list once with the stakeholders from the previous step, then freeze it before the shortlist is built, so the criteria belong to the operation rather than to the vendor who presented most recently.
3.5. Using an RFI and Researching the Vendor Landscape
Only now does the RFI arrive, paired with researching the vendor landscape. The order is the point: an RFI is the structured version of requirements you have already agreed, and a question you cannot phrase clearly is usually a requirement you have not finished thinking about. Research the landscape with the same discipline, because knowing the types from Block 1 lets you discard a whole category with one question instead of three demos.
The selection sequence
Block 3 turns the knowledge into a method, in five moves
The selection sequence. Block 3 defines the operation before it approaches the market: content and volumes first, stakeholders second, requirements third, priorities fourth, and the RFI last.
4. Block 4. Evaluating, Choosing and Negotiating
The fourth block is where the shortlist meets reality, and where the money gets discussed.
4.1. Case Studies, Demos, Trials and Pilots
The course opens this block with evidence rather than sales material: review case studies and customer feedback, then book demos and run realistic trials or pilots. Read the case studies for the right reason, which is not what a vendor did for somebody else but which size of organisation and which workflow the vendor is genuinely good at serving. Then keep the pilot on a clock: a short, well-scoped trial with success criteria agreed in advance produces a defensible result, while an open-ended evaluation produces exhaustion and a decision nobody can justify. Demos and pilots cost time, and the time is best spent on the two or three candidates you could actually live with rather than on a long list you cannot compare.
4.2. Factors Beyond Features
Then come the factors that decide the outcome in year two, after the sales cycle has moved on. The course names scalability, UX, flexibility, support, security, compliance, culture and roadmap. None of them is a checkbox, which is exactly why they disappear from a comparison table: scalability and security are the questions procurement asks late, while UX, flexibility and support are the ones the team feels every day after signing. A vendor with an elegant product and a slow support desk is a vendor you will be explaining to your team for the next two years.
What decides year two
The factors beyond features, and when each one surfaces
What decides year two. The factors the course names beyond features, grouped by when they surface: procurement asks about some of them late, while the team lives with the others every day.
4.3. Comparing Subscription, Per-License and Volume-Based Models
Negotiation gets its own treatment, and it is specific. The commercial shapes to compare are subscription, per-license and volume-based pricing, and the costs around the licence matter as much as the licence itself: connectors, development, support, termination and overall contract costs.
| Pricing model | How it is charged | What to check before comparing |
|---|---|---|
| Subscription | A recurring fee for access to the platform | What the tier includes, how users and content are counted, and the renewal terms |
| Per license | Priced per user or per seat | How many seats the workflow really needs, and how that number grows with the team |
| Volume-based | Priced against the volume of words or content processed | How volume is measured, and what happens to the price when it changes |
Model the same real volume across all three shapes before comparing them, because they diverge sharply depending on how the workload is distributed, and the cheapest headline number is rarely the cheapest at your actual scale. The material also warns against long-term contract lock-ins in a market that keeps changing, which is an argument for agreeing the exit while you still have leverage. Once the costs outside the licence are added, the offers become comparable on the only basis that matters: what you will pay for the work you actually have.
4.4. Building the Business Case
The block closes with the business case, and the course gives it four parts rather than one number.
| Part of the case | The questions it answers |
|---|---|
| Impact on stakeholders | What are the benefits for them, what is the impact on their work, and how can they support you? The audiences are developers and designers, product managers, marketers and copywriters. |
| Alignment with company goals | Are the benefits aligned with what the business is already trying to do: quality, velocity, costs, scalability and geographic expansion? |
| Data and KPIs | Is the system providing the data you need to report on: costs and budgeting, ROI, quality, turnaround time and volumes? |
| Efficiency and automation | Efficiency and automation translate into reduced hours of work and therefore cost reduction, through less project management time and less work for stakeholders because of integrations. |
Keep the KPI set small and honest. Three or four measures the business already tracks will outperform a long list nobody has agreed to own, and they are the ones that get read again at the first annual review. The point of the second row is that the argument is made to the organisation and not to the localization team: a case built only on internal metrics invites the question of whose budget is paying, while a case tied to company goals answers it before it is asked.
5. Block 5. Implementing and Evolving a TMS
The final block is the one most selection processes skip, and it is where the decision either becomes a working system or a licence nobody uses.
5.1. The TMS Implementation Plan
The course names the implementation plan as assigning roles, defining workflows, setting standards, training users, implementing QA and building dashboards. Read as a sequence, that is the plan, and the order is not arbitrary: roles before workflows, because somebody has to own each decision; standards before training, because training has to teach something specific; QA and dashboards last, because they measure what the earlier steps built.
Two of those deliverables deserve separate emphasis. Defining workflows and training users are the pair that decides whether the tool is adopted, and they are consistently underestimated because they look like soft work next to configuration. In practice a workflow nobody was trained on is a workflow the team rebuilds by hand in the first busy week, and that rebuilt version is the one that survives.
5.2. The TMS Migration Checklist
Migration is treated in the same block, and the course frames it as planning changes and migrations with stakeholder buy-in. That phrase carries the whole risk of the exercise: a migration with technical success and no organisational buy-in gets quietly bypassed six months later. The checklist below follows the course's order, from roles through to the buy-in that makes it stick.
1. Assign the roles. Name who owns the migration, the language assets and the integrations before anything moves, because an unassigned migration stalls at the first unexpected file.
2. Define the target workflows on paper. Write the workflow from project creation to re-import of finished work, using the five stages from Block 2; every step you cannot describe is a step you cannot automate.
3. Set the standards. Agree terminology, style rules and quality criteria, because standards are what the training will actually teach and what QA will later enforce.
4. Inventory what travels. List the translation memories, term bases, projects, automations and reports, and be explicit about what you are retiring so nobody assumes it is arriving later.
5. Choose the migration strategy. Decide between a full cut-over, a parallel run and a staged move by content type or market, and write down the reason you chose it.
6. Test with real content. Run a pilot on an actual file, an actual language pair and an actual workflow, because that is the only test that finds the problems you would otherwise meet in production.
7. Train the people, not the tools. Build the sessions around the workflows you wrote in step two, so the team can work rather than merely click.
8. Implement QA inside the system. Move the checks into the tool rather than leaving them at the end, or the migration quietly lowers the standard while everyone is learning the interface.
9. Build the dashboards. Use them to see whether the new workflows are being used, and whether volumes, costs and turnaround times match the business case you wrote in Block 4.
10. Plan the change with stakeholder buy-in. Revisit the impact analysis from the business case, because the people whose work changes are the ones who decide whether the migration holds.
5.3. Evolving the TMS
The block, and the framework, close on the part that has no end date: evaluate TMS performance regularly, and identify issues across scalability, cost, features, UX, integrations, security, support and expansion. That list is deliberately the same family as the evaluation factors from Block 4, which is the course's way of saying that the selection criteria never stop being the management criteria.
Reviewing the system on that basis is how a programme notices that a workflow is being worked around, long before anyone proposes changing tools again. It is also what turns a one-off purchase into a relationship that can be measured, argued for and, when the time comes, replaced on purpose rather than by accident.
6. Compare the Shortlist
A prioritised requirements list needs a side-by-side view before it goes to the people signing the contract, and that is what the TranslaStars CAT, TMS and Tool Comparator is for. It holds 201 tools, each ranked inside its own league against 7 verifiable criteria, and it opens in the browser with no registration.
Use it after the requirements are prioritised, and not before: a comparison engine is only as useful as the criteria you bring to it. Two earlier pages on this blog are useful while you work through the list: the ten most used TMS in 2026 and choosing the right TMS for your localization needs. For the architecture question behind orchestration, see TMS versus headless localization.
7. Where to Start
Five blocks in her order give a selection process that can be defended: understand the category, understand the current market, run the process, argue the money, then plan the delivery and keep evaluating it. Carioni's own summary of the course is that it exists so that localization managers can make defensible, practical decisions aligned with business goals, and that is the standard to hold your own process to.
The most direct way to learn the framework is to take it from the person who uses it. TMS Selection: Strategy, AI & Implementation is the on-demand course, and the live module How to Choose a Translation Management System covers the same lifecycle with live Q&A. Both sit inside the Localization Management Program, next to the rest of the TranslaStars courses for localization managers and operations teams.
Take the framework further. The full TranslaStars course catalogue groups the localization management, project management and AI tracks that this decision touches, so you can build the selection, negotiation and implementation skills in one place.
