And not break your implementation in the process.
A little bit of background…
As most of you probably know, Adobe will be sunsetting on DTM in favor of their more modern tag management system called Adobe Launch.
As people look to evaluate moving from DTM to Launch, they first must decide if they want to migrate their existing DTM implementation or rather take this as an opportunity to reimplement. You may look to reimplement if your data is not trustworthy, your implementation has not grown and changed as business has, or if you are looking to decrease page load time by taking advantage of the asynchronous nature of Launch and move to an event-driven data layer. If you are looking to reimplement, Search Discovery has created new proprietary technology to help give you the most robust dataset as quickly as possible.
If you are not looking to reimplement, and are simply looking to migrate, this article is for you.
There are many reasons why it is a good idea to adopt Adobe Launch (refer to Jim Gordon’s blog post on the subject), and the process has been made easier than ever with the migration tool provided by Adobe in July 2018. At this point, however, the approaching milestones of the DTM sunsetting plan make it more of a necessity than an optional upgrade.
In this post, we want to walk you through the process to efficiently migrate an Adobe DTM property to Adobe Launch. We’ll go step by step and covering all the necessary details and pitfalls you may encounter. So, let’s roll up our sleeves and get started.
Step One: Clean Up Your DTM Account
Most likely, your DTM implementation will contain old third party rules that aren’t used anymore, legacy analytics code for use cases that aren’t applicable any more or tracking that has been broken for a while and nobody noticed.
This isn’t a mandatory step, but it is hard to resist taking advantage of this situation to review all the rules and variables that exist in the DTM property and remove everything that isn’t adding value.
This is a perfect opportunity to speak to agencies, analysts or other stakeholders to get a better understanding of what is and isn’t used, this will reduce the amount of work required since there will be fewer rules to be migrated. This means less effort trying to figure out how and when exactly each rule is supposed to trigger.
Since Adobe’s migration tool only migrates the rules that are in the DTM production environment, we recommend documenting the rules that exist in DTM and remove them once they have been migrated to Launch. This will allow you to update the code in Launch’s development environment without having to push code to production in DTM.
List all the rules in DTM and the tags they contain (each rule may contain more than one tag), identify which tags are used and which are not and document it in a spreadsheet. You can use this document as a reference to remove the tags that aren’t used later on once the property has been migrated to Adobe Launch.
Step Two: Use SDI’s Migration Assessment App
As a result of the effort to make the library lighter, more robust and to support asynchronous loading, some of the functions that were natively supported by Adobe DTM have either been removed from Launch or their syntax has been updated.
Before we migrate a DTM Property to Launch, we need to make sure we have located and listed all the references to these functions, so that we can replace them after we’ve used Adobe’s, Migration Tool.
Sounds tedious? Well, luckily for you, at SDI we have developed a tool that does all this work for you, and it even provides recommendations on how to replace the references to these function calls. We named it DTM to Launch Assessment App, and the best part is that it is free to use.
Scroll down on the link provided until you reach the form:
Fill it in with the URL of your website (or the DTM JS library) and submit the form. The tool will provide an overview of the checks performed and the issues found:
It will also give details on each issue found, categorized by the rule type (Page Load, Event, Direct Call, Data Element or Tool) and the rule name:
For each issue, it’ll give the name of the rule where the issue can be found, whether it is in the condition or in a custom JavaScript rule, the function call, the recommended remedy and a link to detailed documentation.
We highly recommend summarising all this information in a spreadsheet, so you can keep track of our work when you start fixing the issues found.
Step Three: Migrate the DTM Property to Launch
Now that we know what rules can be removed and what migration issues exist in our implementation, we can go ahead and move all the code to Adobe Launch.
Adobe created a tool that makes it super easy to move the code. Although it doesn’t fix any of the issues listed by the Migration Assessment Application on Step 2 of this guide, it moves all the existing rules in DTM to Adobe Launch, setting up all the triggers and custom rules for you.
To use the tool, log in to your Experience Cloud Account, click on the top right grid and click on Launch in the dropdown.
Please note that it is very important to be logged in to the Experience Cloud and not directly in DTM, since otherwise, the migration tool won’t appear in the GUI.
On the next screen, click on the Go to DTM button. This will open up the DTM interface, log in from the Experience Cloud. From there, navigate to your account and then to the property you want to migrate to Launch. You will see the Upgrade to Launch button on the top right side of the screen on the Overview tab:
Click on that button and the migration process will begin. At this point, there are two decisions that have to be made:
1. Do you want to use the DTM Production embed code in Launch production environment?
If you check this box, the existing DTM library (the library in the actual URL) will be replaced with the Launch library when the first version of Launch gets pushed to production. This has important implications:
- It allows upgrading to Adobe Launch without the developers having to change any code on the website.
- You’ll lose the ability to push code to production in Launch without overriding the DTM library.
- You will still be able to roll back to DTM re-publishing the DTM property. This will override the Launch library pushed to production.
In general, if you want the developers to publish the new Launch library to production, leave this box unchecked. This will allow you to make all the changes you need in Adobe Launch. Perform the QA in a development or staging environment, push the Launch changes to Launch’s production environment, provide the library URL to the developers and ask them to replace DTM’s library with Launch’s one on the production site.
If, instead, you prefer to push the changes to production yourself, check this box. In this case, you’ll have to make all the changes in Launch’s development and staging environments and perform QA in either a staging environment of the website or by using a reverse proxy such as Charles. Once you finished your QA, you can push the changes to production and DTM’s live library will be overwritten.
Note that if you want to implement Launch asynchronously, you’ll have to remove the _satellite.pageBottom() call at the bottom of the BODY tag. This change can’t be done from Launch, so it will always have to be done by the developers.
2. Do you want to disable the DTM property after the upgrade?
This option disables the existing DTM property. Leave this unchecked, since it may be useful for reference or to roll back in case something goes wrong during the Launch publish.
Step Four: Make Changes to Launch
At this point, we should have a list of all the tags that we want to remove (from step one), a list of all the issues that we need to remedy (step 2) and a new set of rules added to Adobe Launch. Note that the migration tool names the new Launch property after the DTM property, adding the date on which the migration took place.
So, this step is pretty straightforward; Remove all the legacy rules, tags and data elements in the property and apply the remedies to the issues found by the migration assessment application.
Also, here is a list of common pitfalls and setbacks we found during migrations:
- Launch isn’t very good at reporting errors, if you have a lot of changes in your version, it’ll be challenging to find its origin. To avoid this, compile all the rules right after the migration, and again after every single change. Otherwise, you might find yourself digging into every rule on the property to track down the error.
- Be careful if you utilize Adobe Target in your implementation. Launch does support asynchronous loading with a couple of minor changes to the page source code (adding async to the embed code and removing the call to _satellite.pageBottom()), however, if target is implemented in an asynchronous Launch implementation it can suffer from timing issues and flickering. The main options are going for asynchronous implementation or implementing target outside of Launch.
- The _satellite library (JavaScript object on the page) are completely different from one another, so be cognizant when using calls and other variables inside it.
Step Five: Perform QA in Staging
It is needless to say how important QA is. It is best practice to list the most important use cases for analytics solutions, third party tags, Javascript-based solutions, and write down the expected output on each case.
Be rigorous about this step, and don’t be afraid of going into a great level of detail. If you aren’t sure about how to QA certain solutions, get in touch with the tool experts and ask them to provide instructions on how to QA to ensure a seamless migration of the tags.
The same document can be used for pre-publish and post-publish QA, so be sure to make it as thorough as possible.
When performing pre-production QA, it is extremely important to make sure the environment we are using is exactly the same as production. There are countless instances where code that was working perfectly before production stopped working once published due to changes in the DOM, the data layer or the URL structure.
Step Six: Publish Launch to Production
Whether you asked the developers to replace the embed code or you are planning to publish a brand new code from Launch, now is the time. There are some best practices to follow when publishing these changes:
- Try to publish when there is low traffic, this will reduce the impact if something goes wrong
- Don’t publish on Fridays, it hinders our capacity to react to unexpected eventualities
- If possible, publish in the morning. This gives time to QA and monitor the site after the publish
- Always monitor the website and the data during the minutes, hours and days after the publish
- Let the agencies know when the new library will be published, and inform them as soon as it goes live. Have them aligned to QA the data on their side as well
- Align an agenda of all people who will be involved in the QA and/or any decision making if anomalies are identified
To sum it all up, when moving from DTM to Adobe Launch is a big step, this guide will help you throughout the process. Plan it in detail, don’t rush the migration and follow one step after the other and the transition will go smoothly.
Search Discovery are experts at both tools and have performed over 1000 migrations like this. If you want some support, we will be glad to assist in any aspects of the migration, or to carry it over entirely! Don’t hesitate to reach out.