Selecting a New Translation Management System

Buying an enterprise translation management system is an expensive choice, and it is one that is often made under extreme time pressure. One might have to make a quick decision relying only on a few sales demos or a quick proof of concept implementation. This is often not sufficient to assess the system, and selecting the software feels like a roll of the dice. The buyer may not end up with a clear picture of the system’s functionality and weaknesses until they have completed a lengthy implementation process.

Given the volatility of the TMS technology sector, the best system at one time may not remain as the best solution over time. A buyer may end up stuck with the system and its ongoing costs for many years, only to find themselves pinched again when the opportunity to upgrade comes around again. But the cycle does not need to be repeated. With proper preparation and understanding of key data points and the migration process, it may not be as difficult to rid yourself of the existing system to migrate to a better solution.


Automation is a central concern for any system because it reduces manual work and speeds up the time to market. However, every system will provide different automation features, so it is prudent to create a wishlist of automation features that are or will be critical for your business processes to evaluate potential systems. It is also important to understand the extent to which the system can be customized, in the event that key features are not available out of the box.

Business Processes

Most TMS applications provide some workflow management, project management, user management, and other business-centric components to fulfill specific business requirements. The key to a successful migration is not to focus on what was implemented in the existing system, but rather to document all business requirements and processes outside the context of the system, so as to validate whether or not the new system meets the needs of the organization. Every system comes with its own limitations, and in some cases requirements must be met using workarounds. These “creative solutions” become the norm to end users over time. Stepping back from your existing system and taking account of your needs afresh will guarantee that you approach your new system with concrete requirements.

Translation Memory (TM)

TM is the key intellectual asset in any translation management system. All of the translations reside in the TM so it is important to be able to export the data from these repositories. Typically, the TMS would allow export of the TMs into Translation Memory Exchange (TMX) file format either through the software UI or the software vendor.

It is not uncommon to have some data loss or reduction in TM leverage quality due to system differences. Each system has different filtering and segmentation rules, and may embed additional data within the segments that other systems cannot natively interpret. Some data cleanup and massaging can be done to increase the recovery rate, but it may be less costly to allow the translations to adjust naturally through linguistic review than to spend time recovering a small subset of TM data. More than anything, it’s important to remember that your new translation memory may not produce results that are identical to your old system.

Terminology Database (TD)

If you are using your TMS to maintain glossaries (aka termbases), you will need to export all of them as part of your migration process. Ideally, the TMS would allow export of the termbase into TBX (“TermBase eXchange”) or Excel file formats.

If you are using a term management system to maintain your glossaries, then it is important to understand if the new TMS will be able to integrate with this system. In some cases, you may need to integrate the new TMS using the term management system’s API in order to maintain term consistency throughout your business.


You should verify that any new TMS includes filters that can support all of the file formats used in your organization. This includes custom filters that may have been created to support unique internal needs. It is equally important to verify whether a system includes frameworks for creating new, custom filters, so you can extend the system according to your needs.


A single system cannot usually fulfill all of an organization’s specific requirements without some  customization, particularly when it comes to integrating with other systems. For enterprise firms, it is common to have multiple integrations forming a complete solution that controls the localization process from end to end. Customizations from the existing system should be exhaustively covered when documenting business requirements. The most common integration points are between content management systems, term management systems, machine translation engines, and business process management systems.

In some cases, there are requirements that neither the TMS or other applications can fulfill. For example, business process management that allows a better project management experience, or linguistic quality evaluation for measuring the quality of translations are components. These features are often too expansive to fit into a single system. As a result, it may make sense to develop custom applications to provide more flexibility and control. When possible, a developer or system architect should be available to investigate potential systems’ APIs and extensions to ensure that any functionality not included the system can be developed on demand.


Selecting and migrating to a new TMS does require some effort, but it does not have to be painful. There are many areas of focus depending on the complexity of the requirements, the level of integration the existing TMS has implemented, and the volume of data that needs to be migrated. Moreover, it is important to understand that the intended purpose of most TMS is language processing using linguistic technologies. As a result, you may find a lot of the project and budget management aspects of localization are missing from these applications which arguably should reside outside the TMS. In future blogs, we will explore in specific areas within the TMS and into the realm beyond a traditional TMS.