As of March 2026, we have started a process to migrate all customers from our legacy decision engine (OTS) to our new one (PAT).
Q: Is this necessary for everyone
A: Yes. We want all customers on the new engine. The old one will be retired as soon as it's no longer in use.
Q: What are the benefits?
A: Experience delivery is considerably faster - in many cases we've seen it run with half the response times of the current engine. We can also iterate faster on the new one, and so some features such as friendly names, multiple locations & segments per experience etc. become possible. UI response times are also considerably better, again over twice as fast for key actions.
Q: What if something goes wrong during migration?
A: Migration is isolated. We copy (not move/destroy) your data into a new database, and our team will then inspect all objects to see if they were copied over cleanly or not. You then have the ability to have a look around, and if we are all good we will then remove access to the legacy system.
Q: How long does migration take?
A: The script runs in seconds. Validation can take many hours as we want to be very sure things are fine/clean before progressing.
Q: Can we revert back if issues are found? Do we lose data if so?
A: Yes you can revert back. It will be a snapshot of the moment in time that we migrated, not including new things you've made since them. So reverting 1 day in won't be painful, but 1 month later would be.
Q: Where can I get support if I find issues?
A: Our normal support channels are the right way to reach out to us - JIRA tickets, emails, talking to your Consultant, etc.
Q: Is it possible to test the new tag on a test environment first to ensure it works?
A: It can be tested yes, and the right way to do this is with your current live tests on the prod website, but still running as a test on your machine. There are two ways to achieve this - one is with a simple Draft Tag which is the preview environment we have built into the platform, and with that you'll be able to preview test delivery, metric capture, segmentation, etc. - all the bits you need to be sure the new environment is working. This is similar to how we are testing things internally.
The other way is with Chrome Dev Tools, but requires modifying code on your machine which some developers find handy but isn't something we suggest as general guidance.
Q: Would the implementation cause a pause in any tests?
A: No. The tag update just stops pointing to our old delivery service and instead points to our new PAT service, which would immediately serve the same content.
Q: Is there a potential 1 day of cutover time?
A: The action of migration itself takes seconds.
The 24hr delay mentioned is due to end-users having cached versions of the wt.js tag. So if they have just browsed the website for the first time a second before we make the change, it'll take them 1 day to see content from the new test decision service (PAT).
Practically, this means for a theoretical maximum of 24hrs, users could see a snapshot of things as they are when we migrate. Same tests, same code, same state, etc., until their browser expires our tag and pulls a fresh one. The minimum time to see this new content is of course 0 seconds, if it's the first time the users have been on the site in that 24hr window.
This is the case with any CDN content, and any tag changes you'll make in the platform though - we keep a CDN Cache time to keep Google happy, but that does mean tag-side changes are cached even if test-changes like code, state, segments etc are instant.
Q: Will the tag update be handled entirely by WTO, or is any implementation required from you?
A: Once approved, we will implement everything and let you know when it's done.
Q: How does it affect live tests? Do we keep the data already collected?
A: Live tests are unaffected. We retain data collected, and use the same experiment ids, so tracking continues. (Including GA integrations etc)
Q: Can you explain the update technically and confirm that any custom tag configuration will remain unchanged?
A: The tag update is minimal in terms of code change. We change our wt_lib.js version from 6.0 to 7.0 and point to our new delivery service called PAT.
Q: What's happening to velocity templates?
A: Velocity templates are deprecated, but all current functionality is available under a new method - Accessing dynamic experience parameters
All custom tag code, such as your conversion packages, GTM mirroring, masking, any custom datalayer work etc. will remain unchanged and function as it always has.