Best Practice for Migrating Translated Data from Lower Environments to Production

[Hardik10]

We’re looking for guidance on the best way to handle translated data in ServiceNow when translations are initially created in a lower environment (e.g., Dev or QA). Our goal is to move these translations to production to avoid duplicate translation efforts.

We’ve noticed that while some update sets (tagged with LF: Task number) exist, they only contain the original records and not the translated data. It seems that translated values are not automatically captured in update sets, likely because they are treated as data rather than configuration.

We’re also using the Translation Hub and spoke model, which helps centralize the request mechanism. However, it’s still unclear how to effectively move the translated content to production once it's completed in lower environments.

Questions:

• What is the recommended approach to migrate translated data from non-prod to prod?
• Are there any best practices or tools/scripts to ensure all relevant translation records are captured and moved?
• Is there a way to automate or streamline this process, especially when using Translation Hub?

[Hardik10]

@Alex Coope - SN , is there any best practices around above questions which I can refer?

[Alex Coope - SN]

hi @Hardik10, typically recommendation would be update-sets,

Also, your observation sounds like how "translated_text" fields work, where the translations are actually attached to the source record and not a translation record. Have you reviewed my blog post here about how the 5 translation tables work? - hopefully it makes sense,


Many thanks,
Kind regards

[Hardik10]

Thank you @Alex Coope - SN . That article really help. For topic table's translated text fields are not having translation within the source record. One key difference is the missing serialize attribute which is not visible. I have asked this question on above mentioned blog post due to topic consistency perspective.