Sunday, February 3, 2019

DTM to Launch Migration Tool Overview

There's a lot of buzz currently about upgrading from Dynamic Tag Manager to Launch by Adobe and there's a ton of good materials out there to help us plan and execute the migration successfully. Right off the bat, the three part series from 33Sticks comes to mind which I highly recommend you to read before this. My post will cover Adobe's migration tool which in my opinion provides a rather seamless method for upgrading to Launch. I'll share my experience with it and supplement the information that the Launch product team has already provided. I'm also not trying to provide a complete roadmap to migrate as there's already great content for it but I'm simply giving my opinion on this handy utility. Let's get started!


The migration tool is basically accessed by clicking the 'Upgrade to Launch' (highlighted in Red) button in DTM as shown below. 

When you click this button, a popup will appear that shows you two check boxes and an 'Upgrade' button. The first checkbox allows you to use the same DTM embed code with Launch post migration. The second checkbox disables the existing property in DTM.

Once you click 'Upgrade', you'll see a brief message stating that the property is being migrated. Once that goes away, you'll see a link which will take you directly to the newly migrated Launch property. The new property in Launch contains the timestamp in its name as shown. 

An important point to note is that only items that have been published in DTM will get migrated and anything that's unapproved in DTM will not get migrated to Launch. Here's a link from Adobe's documentation that covers what all will be migrated (Adobe Analytics, ECID, rules and data elements). 

In case you want to migrate any additional rules that weren't previously migrated during the first round, you can migrate the property from DTM again. In my case, I forgot to publish a few rules in DTM that weren't migrated before so I ended up migrating the property again which added a second property in Launch with a different timestamp. Personally, I would recommend that you migrate just once and publish everything in DTM beforehand.

As far as the (migrated) rules are concerned, Launch creates a new rule to fire off an Analytics beacon (see below) in addition to the ones that get migrated.

Now that we've seen what the migration tool does, I want to share how I would approach a migration with this tool.

My Migration Approach

Before I begin, I want to share that I've upgraded a few clients using this tool as well as migrated clients by creating a brand new property in Launch. There's no hard and fast rule around which method to choose as both options will get you the desired results but if you have a very complicated Analytics set, the migration tool might be a better solution. Let's go through what my approach would be with the migration tool.

  • Treat this migration as an opportunity to do a cleanup of unnecessary data elements and rules and validate your data layer and tags in general.
  • Create a thorough launch schedule/plan to QA your staging environment and sure all tags are firing as expected. There's a lot of good material out there on how to build use cases and leverage QA tools & extensions to perform validation but that's a separate post for some other day but give this step the utmost importance.
  • Your launch plan needs to include a timeline of how long your tags will be tested in staging and when can they be pushed to production. I would typically give it about a month (depending on the complexity of your site) from when you begin testing in staging to when you can deploy Launch in production.
  • Make sure to publish all rules, data elements and tools in DTM that you want to migrate to Launch. As mentioned earlier, only Adobe Analytics and Experience Cloud ID Service tools will be migrated so other solutions such as Target or Ad Cloud will have to be created separately in Launch.
  • Click the 'Upgrade to Launch' button and do not select any of the checkboxes in the popup. The reason why I wouldn't select the DTM embed code option is because it's recommended to deploy Launch asynchronously which doesn't require the legacy pageBottom() call. As this call will have to be removed, there's no real advantage in keeping the DTM tag as you'll still need a release cycle to make this change. The other checkbox to disable the DTM property shouldn't be checked as you may need to go into DTM later.
  • Once the new (migrated) Launch property has been created, click into the property and do a quick sanity check to make sure all rules, data elements and the Analytics/ECID extensions have been copied over correctly. At this time, add any extensions in Launch that didn't get copied over from DTM such as Target. I've covered AAM separately in the last section.
  • Replace your existing DTM code hosted in your staging environment with the Launch embed code to begin your tag validation. Click the 'Environments' tab and copy the development script as shown below.

  • Test in staging and closely follow your migration plan. After meeting all your validation criteria, publish your new Launch property in production.

Audience Manager SSF Migration

If you had Audience Manager deployed via server side forwarding (SSF) in DTM, the AAM module will get copied over to Launch and the module will be present in the Analytics extension. My recommendation is for you leverage the in-built SSF integration for AAM inside the Analytics extension. Let's take a look.

Click 'Open Editor' in the Analytics extension.

Comment out the AAM module code in the library and save changes.

Choose 'Manage the library for me' option to let Launch host your Analytics library as well as automatically upgrade you AppMeasurement library. Also 'globalize' your Analytics object so that you can leverage the object elsewhere in Launch and in the browser console.

Finally, check the checkbox as shown below to enable the automatic AA->AAM SSF integration in Launch.

So that's a wrap. I hope you found this walkthrough helpful in case you decide to go with the migration tool but whatever approach you choose, it's imperative to have a sound migration plan and validation strategy.