{"id":542,"date":"2018-10-29T20:17:00","date_gmt":"2018-10-29T20:17:00","guid":{"rendered":"https:\/\/www.digitaldatatactics.com\/?p=542"},"modified":"2020-09-17T21:15:19","modified_gmt":"2020-09-17T21:15:19","slug":"dtm-to-launch-migration-series-1-options-and-considerations","status":"publish","type":"post","link":"https:\/\/www.digitaldatatactics.com\/index.php\/2018\/10\/29\/dtm-to-launch-migration-series-1-options-and-considerations\/","title":{"rendered":"DTM-to-Launch Migration Series #1: Options and Considerations"},"content":{"rendered":"\n
\"33<\/figure><\/div>\n\n\n\n

(cross-posted from the 33 Sticks Blog<\/a>)<\/p>\n\n\n\n

Adobe\u2019s Launch is really building momentum (they just announced the plan to sunset DTM<\/a>\u2013 editing abilities end December 31st, 2019<\/del> July 1st, 2020; read-only access dies June 2020<\/del> December 31st, 2020 (dates updated to reflect Adobe\u2019s change)), and in the past few months, it feels like almost every day, I get asked \u201cwhat does a launch migration look like?\u201d<\/p>\n\n\n\n

And I\u2019m afraid I have a very unhelpful answer: it totally depends<\/strong>.<\/p>\n\n\n\n

We\u2019ve 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 \u201cit depends\u201d by clarifying what it depends on, what the options are, and what considerations should you make.<\/p>\n\n\n\n

WHAT YOU NEED TO KNOW<\/h3>\n\n\n\n

Preparing to Migrate<\/strong>
 Adobe DTM to Launch Migration Options<\/a>
 Things to be aware when moving from DTM to Launch<\/a><\/p>\n\n\n\n

Using the Migration as an Opportunity<\/strong>
 Redo your property structure<\/a>
 Define standards within Launch<\/a>
 Clean up redundant\/unused items<\/a>
 Best practices for Rule scope\/conditions<\/a>
 Institute a Naming Schema<\/a>
 Fix up your data layer<\/a>
 Optimize your third party tags<\/a>
 Document everything<\/a>
 Change your deployment method<\/a>
 How to use the download option<\/a>
 Update your visitorID\/appMeasurement libraries<\/a>
 Update cross-Adobe Tool integrations<\/a><\/p>\n\n\n\n

The Migration Process<\/strong>
 How to roll out Launch<\/a>
 Validation<\/a>
 Audit what you have (and figure out what you want)<\/a>
 Decide on a publishing flow that works for your org<\/a>
 Create a Migration Project Plan<\/a>
 Other Resources and Next Steps<\/a><\/p>\n\n\n\n

Disclaimer:<\/strong> 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.<\/em><\/p>\n\n\n\n

You\u2019ve Got Options<\/h1>\n\n\n\n

As far as we see it, if you\u2019re considering a move from Adobe DTM to Launch, you have a few options:<\/p>\n\n\n\n

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

    Most folks we\u2019ve talked to or worked with are looking at somewhere in that 2-3 range. In most cases, we\u2019d 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.<\/p>\n\n\n\n

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

    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<\/a>). 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.<\/p>\n\n\n\n

    Consider the following questions:<\/h3>\n\n\n\n

    Are you currently using DTM for Single Page Apps<\/strong>? (if so, you\u2019ve almost certainly had to use some workarounds that are no longer needed)<\/p>\n\n\n\n

    Do you have any repeated global logic<\/strong> (all of your DCRs or EBRs might be setting \u201ceVar5=%auth status%\u201d because you didn\u2019t have a way to get that eVar included on all beacons otherwise)<\/p>\n\n\n\n

    Do you use Direct Call Rules heavily<\/strong>?<\/p>\n\n\n\n

    Do you have s.clearVars<\/strong> running in odd places?<\/p>\n\n\n\n

    Are a large portion of your Analytics variables being set in custom code blocks<\/strong> instead of in the interface?<\/p>\n\n\n\n

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

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

    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:<\/strong><\/p>\n\n\n\n