(cross-posted from the 33 Sticks Blog)
Adobe’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
Adobe DTM to Launch Migration Options
Things to be aware when moving from DTM to Launch
Using the Migration as an Opportunity
Redo your property structure
Define standards within Launch
Clean up redundant/unused items
Best practices for Rule scope/conditions
Institute a Naming Schema
Fix up your data layer
Optimize your third party tags
Document everything
Change your deployment method
How to use the download option
Update your visitorID/appMeasurement libraries
Update cross-Adobe Tool integrations
The Migration Process
How to roll out Launch
Validation
Audit what you have (and figure out what you want)
Decide on a publishing flow that works for your org
Create a Migration Project Plan
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:
- Use the DTM-to-Launch Migration tool (SEE: Adobe’s documentation), essentially just doing a lift-and-shift of your current DTM implementation.
- Use the DTM-to-Launch migration tool, but do a fair amount of clean up before/after.
- 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).
- 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:
- Launch allows you to pass extra parameters in Direct Call Rules (eg _satellite.track(“add to cart”,{name:”wug”,price:”12.99″,color:”red”}))
- 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.
- Launch has other improvements for Single Page Apps (clearVars, conditions on Direct Call Rules, etc)
- Launch is engineered for better Page Performance
- 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
- 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).