How to Best Migrate from DTM to Launch

by Oct 29, 2019

And not break your implementation in the process.

A little bit of back­ground…

As most of you prob­a­bly know, Adobe will be sunset­ting on DTM in favor of their more modern tag manage­ment system called Adobe Launch.

As people look to eval­u­ate moving from DTM to Launch, they first must decide if they want to migrate their exist­ing DTM imple­men­ta­tion or rather take this as an oppor­tu­nity to reim­ple­ment. You may look to reim­ple­ment if your data is not trust­wor­thy, your imple­men­ta­tion has not grown and changed as busi­ness has, or if you are looking to decrease page load time by taking advan­tage of the asyn­chro­nous nature of Launch and move to an event-driven data layer. If you are looking to reim­ple­ment, Search Discovery has created new propri­etary tech­nol­ogy to help give you the most robust dataset as quickly as possi­ble.

If you are not looking to reim­ple­ment, 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 migra­tion tool provided by Adobe in July 2018. At this point, however, the approach­ing mile­stones of the DTM sunset­ting plan make it more of a neces­sity than an optional upgrade.

In this post, we want to walk you through the process to effi­ciently migrate an Adobe DTM prop­erty to Adobe Launch. We’ll go step by step and cover­ing all the neces­sary 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 imple­men­ta­tion will contain old third party rules that aren’t used anymore, legacy analyt­ics code for use cases that aren’t applic­a­ble any more or track­ing that has been broken for a while and nobody noticed.

This isn’t a manda­tory step, but it is hard to resist taking advan­tage of this situ­a­tion to review all the rules and vari­ables that exist in the DTM prop­erty and remove every­thing that isn’t adding value.

This is a perfect oppor­tu­nity to speak to agen­cies, analysts or other stake­hold­ers to get a better under­stand­ing 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 migra­tion tool only migrates the rules that are in the DTM produc­tion envi­ron­ment, we recom­mend docu­ment­ing 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 devel­op­ment envi­ron­ment without having to push code to produc­tion in DTM.

List all the rules in DTM and the tags they contain (each rule may contain more than one tag), iden­tify which tags are used and which are not and docu­ment it in a spread­sheet. You can use this docu­ment as a refer­ence to remove the tags that aren’t used later on once the prop­erty 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 asyn­chro­nous loading, some of the func­tions that were natively supported by Adobe DTM have either been removed from Launch or their syntax has been updated.

Before we migrate a DTM Prop­erty to Launch, we need to make sure we have located and listed all the refer­ences to these func­tions, so that we can replace them after we’ve used Adobe’s, Migra­tion Tool.

Sounds tedious? Well, luckily for you, at SDI we have devel­oped a tool that does all this work for you, and it even provides recom­men­da­tions on how to replace the refer­ences to these func­tion calls. We named it DTM to Launch Assess­ment 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, cate­go­rized 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 condi­tion or in a custom JavaScript rule, the func­tion call, the recom­mended remedy and a link to detailed docu­men­ta­tion.

We highly recom­mend summaris­ing all this infor­ma­tion in a spread­sheet, 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 migra­tion issues exist in our imple­men­ta­tion, 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 Migra­tion Assess­ment Appli­ca­tion on Step 2 of this guide, it moves all the exist­ing rules in DTM to Adobe Launch, setting up all the trig­gers and custom rules for you.

To use the tool, log in to your Expe­ri­ence Cloud Account, click on the top right grid and click on Launch in the drop­down.

Please note that it is very impor­tant to be logged in to the Expe­ri­ence Cloud and not directly in DTM, since other­wise, the migra­tion tool won’t appear in the GUI.

On the next screen, click on the Go to DTM button. This will open up the DTM inter­face, log in from the Expe­ri­ence Cloud. From there, navi­gate to your account and then to the prop­erty 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 migra­tion process will begin. At this point, there are two deci­sions 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 exist­ing DTM library (the library in the actual URL) will be replaced with the Launch library when the first version of Launch gets pushed to produc­tion. This has impor­tant impli­ca­tions:

  1. It allows upgrad­ing to Adobe Launch without the devel­op­ers having to change any code on the website.
  2. You’ll lose the ability to push code to produc­tion in Launch without over­rid­ing the DTM library.
  3. You will still be able to roll back to DTM re-publish­ing the DTM prop­erty. This will over­ride the Launch library pushed to produc­tion.

In general, if you want the devel­op­ers to publish the new Launch library to produc­tion, leave this box unchecked. This will allow you to make all the changes you need in Adobe Launch. Perform the QA in a devel­op­ment or staging envi­ron­ment, push the Launch changes to Launch’s produc­tion envi­ron­ment, provide the library URL to the devel­op­ers and ask them to replace DTM’s library with Launch’s one on the produc­tion site.

If, instead, you prefer to push the changes to produc­tion your­self, check this box. In this case, you’ll have to make all the changes in Launch’s devel­op­ment and staging envi­ron­ments and perform QA in either a staging envi­ron­ment of the website or by using a reverse proxy such as Charles. Once you finished your QA, you can push the changes to produc­tion and DTM’s live library will be over­writ­ten.

Note that if you want to imple­ment Launch asyn­chro­nously, 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 devel­op­ers.

2. Do you want to disable the DTM property after the upgrade?

This option disables the exist­ing DTM prop­erty. Leave this unchecked, since it may be useful for refer­ence or to roll back in case some­thing 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 migra­tion tool names the new Launch prop­erty after the DTM prop­erty, adding the date on which the migra­tion took place.

So, this step is pretty straight­for­ward; Remove all the legacy rules, tags and data elements in the prop­erty and apply the reme­dies to the issues found by the migra­tion assess­ment appli­ca­tion.

Also, here is a list of common pitfalls and setbacks we found during migra­tions:

  • Launch isn’t very good at report­ing errors, if you have a lot of changes in your version, it’ll be chal­leng­ing to find its origin. To avoid this, compile all the rules right after the migra­tion, and again after every single change. Other­wise, you might find your­self digging into every rule on the prop­erty to track down the error. 
  • Be careful if you utilize Adobe Target in your imple­men­ta­tion. Launch does support asyn­chro­nous loading with a couple of minor changes to the page source code (adding async to the embed code and remov­ing the call to _satellite.pageBottom()), however, if target is imple­mented in an asyn­chro­nous Launch imple­men­ta­tion it can suffer from timing issues and flick­er­ing. The main options are going for asyn­chro­nous imple­men­ta­tion or imple­ment­ing target outside of Launch.
  • The _satellite library (JavaScript object on the page) are completely differ­ent from one another, so be cognizant when using calls and other vari­ables inside it.

Step Five: Perform QA in Staging

It is need­less to say how impor­tant QA is. It is best prac­tice to list the most impor­tant use cases for analyt­ics solu­tions, third party tags, Javascript-based solu­tions, and write down the expected output on each case.

Be rigor­ous 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 solu­tions, get in touch with the tool experts and ask them to provide instruc­tions on how to QA to ensure a seam­less migra­tion of the tags.

The same docu­ment can be used for pre-publish and post-publish QA, so be sure to make it as thor­ough as possi­ble.

When perform­ing pre-produc­tion QA, it is extremely impor­tant to make sure the envi­ron­ment we are using is exactly the same as produc­tion. There are count­less instances where code that was working perfectly before produc­tion stopped working once published due to changes in the DOM, the data layer or the URL struc­ture.

Step Six: Publish Launch to Production

Whether you asked the devel­op­ers to replace the embed code or you are plan­ning to publish a brand new code from Launch, now is the time. There are some best prac­tices to follow when publish­ing these changes:

  • Try to publish when there is low traffic, this will reduce the impact if some­thing goes wrong
  • Don’t publish on Fridays, it hinders our capac­ity to react to unex­pected even­tu­al­i­ties
  • If possi­ble, 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 agen­cies 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 deci­sion making if anom­alies are iden­ti­fied

To sum it all up, when moving from DTM to Adobe Launch is a big step, this guide will help you through­out the process. Plan it in detail, don’t rush the migra­tion and follow one step after the other and the tran­si­tion will go smoothly.

Search Discovery are experts at both tools and have performed over 1000 migra­tions like this. If you want some support, we will be glad to assist in any aspects of the migra­tion, or to carry it over entirely! Don’t hesi­tate to reach out.

Do You Want Some Help with the Migration?

Reach out to learn more about how we can help.

I consent to having Search Discovery use the provided infor­ma­tion for direct market­ing purposes includ­ing contact by phone, email, SMS, or other elec­tronic means.