How to Best Migrate from DTM to Launch

Migrate from DTM to Launch: Introduction/Background

As you know, Adobe will be sunsetting on DTM for their latest tool called Adobe Launch.

People are looking to assess switching from DTM to Launch, they must first determine whether to move their current DTM implementation or rather take this as an opportunity to re-implement it.

If your information is not trustworthy, your implementation has not grown and changed as business has, or if you want to minimize page load time by taking advantage of Launch’s asynchronous design and shifting to an event-driven data layer, you the look for re-implementation.

Search Discovery can help you get the most robust data as quickly as possible with proprietary technology.

If you don’t want to re-implement and just want to move, this article is for you.

Image result for dtm to launch migration"

In the article, we will cover all the information and pitfalls you will encounter to migrate from DTM -> Launch. So, let’s continue rolling up our sleeves and migrate from DTM to Launch.

Step One:

Clean Up Your DTM Account
More probably, the DTM implementation would include:

  • Old third-party rules that are no longer used
  • Outdated analytics software for cases that are no longer applicable
  • Monitoring that has been broken for some time and no one has noticed

This is a perfect opportunity to talk to agencies, analysts or other stakeholders in order to get a better understanding of what is and is not being used, this will reduce the amount of work required as there will be less rules to migrate. This means less time trying to figure out exactly how and when to trigger that rule.

Since the migration tool of Adobe only migrates the rules in the production environment of DTM, we suggest recording the rules that exist in DTM and deleting them once they are migrated to Launch. This will allow you to update the code in the development environment of Launch without moving code to DTM production.

Step Two:

Use SDI’s Migration Assessment App
Some of the functions that were natively supported by Adobe DTM were either removed from Launch or their syntax was updated as a result of the effort to make the library lighter, more robust and support asynchronous loading.

Before migration we need to make sure we have identified all references to these functions to remove them later.

At SDI, we’ve developed DTM to Launch Assessment App for free usage that does all of this for you.

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 and the rule name:

The rule name will be provided wherever the problem is found for each question.

It is highly recommended to compile all data in a spreadsheet to keep a track.

Step Three:

Migrate the DTM Property to Launch
Now that we know what rules can be omitted and what migration problems are in our implementation, we can move the entire code to Adobe Launch.

Now that we know what rules can be omitted and what migration problems are in our implementation, we can move the entire code to Adobe Launch.

Adobe has created a tool that makes moving the code super easy. Although it does not address any of the issues listed on Step 2 of this guide in the Migration Assessment Application it moves all existing DTM rules to Adobe Launch setting all the triggers and custom rules for you.

Sign in to your Experience Cloud Account to use the app, click on the top right grid and click Launch in the dropdown.

Please note that logging into the Experience Cloud is very necessary and not directly in DTM, as otherwise the migration tool will not appear in the GUI.

Continue reading to successfully migrate from DTM to Launch

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 the button and the process of migration will begin. There are two decisions to make at this point:

1.Would you like to use the embedded DTM Production code in the production environment of Launch?
Checking this box would replace the existing DTM library (the library in the actual URL) with the Launch library when Launch’s first version is put into development. This has important implications:

  • It allows Adobe Launch to update any code on the website without developer’s help.
  • By overriding the DTM library, you will lose the ability to put code into development in Launch.
  • 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 particular, leave this box unchecked if you want developers to release the new Launch library for production. This will enable you in Adobe Launch to make all the changes you need. 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. You can move the changes to production once you have completed your QA and the live library of DTM will be overwritten.

You’ll have to remove the _satellite.pageBottom() call at the bottom of the BODY tag to implement launch asynchronously. The change can’t be made from launch, so developers will always have to make it.

2. You want the DTM property to disable after the upgrade?This option deactivates the existing DTM property. Keep this unchecked, to use it for comparison later.

Step Four:

Make Changes to Launch
We should have a list of all the tags we want to delete at this stage (from step one), a list of all the problems we need to correct (step 2) and a new set of rules applied to Adobe Launch. Notice that after the DTM property, the migration tool calls the new Launch property, adding the date the migration occurred.

Therefore, this step is quite straightforward; delete all the property’s legacy laws, tags and data elements and apply the solutions to the issues found by the application for migration assessment.

Also, here is a list of common pitfalls and setbacks we found during migrations:

  • Launch is’nt good at reporting errors, it will be challenging to find its origin if you have a lot of changes in your version. Compile all the rules right after the migration, and again after each change, to avoid this. Otherwise, to track the mistake, you can find yourself digging into every property rule.
  • 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 to implement asynchronous targets outside of Launch and incorporate them.
  • 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
How important QA is is, it is needless to say. Listing the most appropriate use cases for analytics solutions, third-party tags, Javascript-based solutions, and writing down the planned performance on each case is best practice.

Be rigorous in this step, and don’t be afraid to go into great detail.

In pre-publishing or post-publishing QA, the same document can be used, so make sure it is as thorough as possible.

When performing QA pre-production, ensuring that the environment we use is exactly the same as production is extremely important. There are countless instances where, due to changes in the DOM, the data layer or the URL structure, code worked perfectly until production stopped working when released.

Step Six:

Publish Launch to Production
Whether you’re asking developers to update the embed code or you’re planning to launch a brand new code from Launch now’s the time. There are some good practices to follow post publishing of these changes:

  • Try to publish when traffic is small, if something goes wrong, this will reduce the impact
  • Do not publish on Fridays, it will hamper our ability to respond to unexpected events
  • If possible, publish in the morning. This gives time to QA and monitor the site after the publish
  • Also track the website and the information in the minutes, hours and days following publishing
  • Let the agencies know the release date of the new library and let them know as soon as it goes online. Have the data on their side matched with QA
  • Post identification of the anomalies, align the agenda of all individuals involved in the QA and/or any decision making

To sum up, this guide will help you throughout the transition because switching from DTM to Adobe Launch is a big step. Plan it in detail, don’t hurry the transfer, proceed step by step, and the process will go smoothly.

Need help with Digital Analytics? Get in touch: