Introducing a new Translation Management System (TMS) sounds like an exciting new beginning for some, and an open-ended nightmare for others. In order to prevent the latter from occurring, good and careful preparation must be made. Then the move can succeed without nasty surprises or unpleasant delays, and you can use the opportunity to shed some outdated practices.

Why change the TMS?

The reasons for changing a system are varied, and the decision is not always yours to make.

• The legacy system is discontinued: The provider discontinues support or changes the licensing model so fundamentally that staying is no longer an option.
• The system is no longer up to date: Lack of cloud capability, a UX from a bygone era, and no open or missing interfaces to important new systems in your infrastructure.
• New requirements arise: More languages, changed data volumes, new file formats, more complex workflows, more modern technology requirements. As a result, the old system can no longer handle it.
• Sometimes the corporate decision comes from above, with no involvement of the language department. That too is a reality — and even then, how well you prepare will determine how well the transition goes.

Planning: What should be clarified before the first click

The most common mistake in system migrations doesn’t happen during setup, it happens before it. Anyone who starts without clean preparation will pay for the failures later on.

Before selecting a system, all requirements must be on the table. What are must-haves, what are nice-to-haves? Which features of the target system are you planning to actively use, and is your existing infrastructure ready to support them? In this phase, all stakeholders should be consulted — from IT and direct users to the representatives of any connected systems. The right system is then evaluated and selected based on these requirements. To find out how blc can help you find the right solution, click here.

The next step is to determine how the new TMS fits into your system architecture. How does it sit within the existing IT landscape? What interfaces are needed: to the CMS, billing systems, AI components, and the project management system? Who builds and maintains these interfaces? And has an IT security review been completed? These are technical questions, but they need to be raised and driven by those responsible for localization.

Construction: Care pays off

With planning in place, the focus shifts to setting up the new system. And here, care matters more than speed.

For the new tool to integrate smoothly into your content processes, the necessary interfaces need to be set up and tested early, with clear acceptance criteria in place. The required workflows should be configured in the new system and documented as you go. At this stage, the authorization concept is also implemented: roles are created, access rights are granted, and visibility is defined for TMs and termbases.

The TM migration itself is a critical step: migrate carefully, then test thoroughly. If 100% matches are lost during migration, the cost in both time and money can be significant. Migrate and validate termbases in parallel. blc is at your side when it comes to managing and migrating your language data.

Finally, it’s time to bring people into the picture. Training is needed for all user groups, but not everyone needs the same level. More important than theory alone is giving users hands-on access to the system early on. Encourage learning by doing, actively gather feedback, and incorporate it into the configuration.

Testing: Please do not skip

Testing is the part that gets cut short or overlooked first when time pressure sets in. That is a mistake.

Before running any pilot, the system should be tested under realistic load conditions. Load tests can be showstoppers that block everything else, so schedule them early, in coordination with IT. Catching issues at this stage is far better than being caught off guard in live operation.

Once a basic configuration is in place, the entire process should be run end to end, from initial authoring through to the delivery and use of translated content. It may not be necessary to test all languages, but all stakeholders should be involved. The system is not ready until it runs smoothly.

When configuration and migration are at a solid level, it’s time to get serious. A pilot project is a good option. Choose a project type that is as complex as needed, but as straightforward as possible, with real users, real content, real workflows, and realistic KPIs. Follow up with an honest evaluation and any necessary configuration adjustments before the full roll-out.

Good to know: testing doesn’t end at go-live. Most systems update automatically or release updates on a regular basis. These should always be reviewed carefully to catch any undesirable side effects of new features before they surface in a live project.