DTM-to-Launch Migration Series #1: Options and Considerations

LaunchAdobe’s Launch is really building momentum (they just announced the plan to sunset DTM– editing abilities end December 31st, 2019 July 1st, 2020; read-only access dies June 2020 December 31st, 2020 (dates updated to reflect Adobe’s change)), and in the past few months, it feels like almost every day, I get asked “what does a launch migration look like?”

And I’m afraid I have a very unhelpful answer: it totally depends.

We’ve had visibility into about a dozen migrations now, and each one has been a completely unique case. But I figured I can at least defend my answer of “it depends” by clarifying what it depends on, what the options are, and what considerations should you make.

WHAT YOU NEED TO KNOW

Preparing to Migrate
[icon name=”check-circle” class=”” unprefixed_class=””] Adobe DTM to Launch Migration Options
[icon name=”check-circle” class=”” unprefixed_class=””] Things to be aware when moving from DTM to Launch

Using the Migration as an Opportunity
[icon name=”check-circle” class=”” unprefixed_class=””] Redo your property structure
[icon name=”check-circle” class=”” unprefixed_class=””] Define standards within Launch
[icon name=”check-circle” class=”” unprefixed_class=””] Clean up redundant/unused items
[icon name=”check-circle” class=”” unprefixed_class=””] Best practices for Rule scope/conditions
[icon name=”check-circle” class=”” unprefixed_class=””] Institute a Naming Schema
[icon name=”check-circle” class=”” unprefixed_class=””] Fix up your data layer
[icon name=”check-circle” class=”” unprefixed_class=””] Optimize your third party tags
[icon name=”check-circle” class=”” unprefixed_class=””] Document everything
[icon name=”check-circle” class=”” unprefixed_class=””] Change your deployment method
[icon name=”check-circle” class=”” unprefixed_class=””] How to use the download option
[icon name=”check-circle” class=”” unprefixed_class=””] Update your visitorID/appMeasurement libraries
[icon name=”check-circle” class=”” unprefixed_class=””] Update cross-Adobe Tool integrations

The Migration Process
[icon name=”check-circle” class=”” unprefixed_class=””] How to roll out Launch
[icon name=”check-circle” class=”” unprefixed_class=””] Validation
[icon name=”check-circle” class=”” unprefixed_class=””] Audit what you have (and figure out what you want)
[icon name=”check-circle” class=”” unprefixed_class=””] Decide on a publishing flow that works for your org
[icon name=”check-circle” class=”” unprefixed_class=””] Create a Migration Project Plan
[icon name=”check-circle” class=”” unprefixed_class=””] Other Resources and Next Steps

Disclaimer: Info in this series is accurate as of, October 29, 2018. We will try to update it as it makes sense to do so, but things can change quickly in the world of TMSes and iterative product releases.

You’ve Got Options

As far as we see it, if you’re considering a move from Adobe DTM to Launch, you have a few options:

  1. Use the DTM-to-Launch Migration tool (SEE: Adobe’s documentation), essentially just doing a lift-and-shift of your current DTM implementation.
  2. Use the DTM-to-Launch migration tool, but do a fair amount of clean up before/after.
  3. Use a tool like Tagtician to audit what you currently have, decide what you want to carry over, and set it up “fresh” in Launch (have Launch accomplish the same thing as DTM, but perhaps accomplish it in different ways).
  4. Use this as a chance to rebuild your solution from the ground up.

Most folks we’ve talked to or worked with are looking at somewhere in that 2-3 range. In most cases, we’d strongly discourage going with option #1, that straight-up lift-and-shift. I PROMISE there is some room for review and improvement in your DTM implementation.

First, not everything in DTM will work in Launch. Our friends at Search Discovery have a great tool for detecting places within DTM that you may be using code that will no longer work (goodbye, _satellite.getQueryParam). (NOTE: this detects places in your DTM library you are using those “forbidden” functions- if you are using something like _satellite.getQueryParam in your own javascript outside of DTM, it will not detect it.)

Technically, aside from the things that that tool will flag, everything that worked in DTM should work in Launch (actually, there are a few major differences you should be aware of). BUT, many of the workarounds you may have resorted to in DTM are no longer needed, so you can definitely optimize things. There are some broader differences between DTM and Launch that open the door for some changes to your implementation that could be really valuable.

Consider the following questions:

Are you currently using DTM for Single Page Apps? (if so, you’ve almost certainly had to use some workarounds that are no longer needed)

Do you have any repeated global logic (all of your DCRs or EBRs might be setting “eVar5=%auth status%” because you didn’t have a way to get that eVar included on all beacons otherwise)

Do you use Direct Call Rules heavily?

Do you have s.clearVars running in odd places?

Are a large portion of your Analytics variables being set in custom code blocks instead of in the interface?

Do you fire any Direct Call Rules from within your DTM implementation (eg, DCRs calling other DCRs to get around timing/scope issues?)

Are you currently firing Adobe Analytics beacons from outside of the Analytics Tool (eg, are you using a third party tag box to fire s.t or s.tl because of timing issues?)

If you answered yes to any of the above questions (and perhaps even if not), then you absolutely should be considering moving to Launch ASAP, for all the reasons discussed on these other blog posts:

[icon name=”rocket” class=”” unprefixed_class=””] Launch allows you to pass extra parameters in Direct Call Rules (eg _satellite.track(“add to cart”,{name:”wug”,price:”12.99″,color:”red”}))

[icon name=”rocket” class=”” unprefixed_class=””] In Launch, you can control the order that rules fire in, and which rules fire an analytics beacon, which has a huge impact for Single Page Apps.

[icon name=”rocket” class=”” unprefixed_class=””] Launch has other improvements for Single Page Apps (clearVars, conditions on Direct Call Rules, etc)

[icon name=”rocket” class=”” unprefixed_class=””] Launch is engineered for better Page Performance

[icon name=”rocket” class=”” unprefixed_class=””] Launch’s publication flow is much more flexible, making it easier to publish only what you want to publish to either Dev (as many environments as you want), Staging or Production

[icon name=”rocket” class=”” unprefixed_class=””] Even if you don’t have a Single Page App, or you are currently using any weird work-arounds to get DTM to work for you, you should use a migration as an opportunity to improve your implementation (which leads us to post 2 in the series: A Golden Opportunity).

[author] Jenn Kunz [author_image timthumb=’on’]https://33sticks.com/wp-content/uploads/2018/03/Jenn.Kunz_.jpeg [/author_image] [author_info]Jenn is an industry expert on Adobe Analytics, Implementation, Tag Management, and Data Layers. Her favorite video game is currently Horizon Zero Dawn, her favorite board game is currently Ex Libris, and her favorite books are the Stormlight Archive by Brandon Sanderson.

She is based out of Marietta, Georgia.[/author_info] [/author]

Published by Jenn Kunz

Jenn is an industry expert on Adobe Analytics, Implementation, Tag Management, and Data Layers. Her favorite video game is currently Horizon Zero Dawn, her favorite board game is currently Ex Libris, and herfavorite books are the Stormlight Archive by Brandon Sanderson. She is based out of Marietta, Georgia.

Join the Conversation

7 Comments

  1. Nice one, a few points I want to call out.

    #1 Without making any new changes to existing web page test all your changes locally using switcheroo chrome plugin, that way we can save a lot of time moving code to dev/stage/production
    #2 Out of box serialization is not working with Launch interface, write the custom code and double check the serialization
    #3 For third party pixels use DOM Ready to avoid conflicts with DOM structure especially if you are loading the library in a sync manner

    1. You’re right! The dates have changed- apparently Adobe decided to give folks a little more time. The correct dates are the ones on that link- “editing abilities end 07-01-2020; read-only access dies 12-31-2020”.

  2. In our firm, we are using a different approach. we are placing both the DTM and Launch embed code on the pages and using dummy report suites in launch for testing,but the tags are getting duplicated for launch and dtm sitecatalyst is not showing up on the page’s network tab despite different embed codes for each one of them, what could be the possibly going wrong?

    1. I’m afraid that the two embed codes can’t exist on the same page- they will overwrite each other and there will be conflicts. They both use the _satellite object (sometimes in slightly different ways) so Adobe doesn’t support it- with good reason, because it breaks. You can have DTM on some pages of your site, and Launch on other pages, but you can’t have both on the same page.

Leave a comment

Your email address will not be published. Required fields are marked *