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

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

Thus far in this series, we\u2019ve discussed your options for a DTM-to-Launch Migration<\/a>, and some potential areas you can improve upon your solution<\/a> as part of a migration. As you can see from my previous posts, there are a lot of possible considerations for a DTM-to-Launch migration. So what might the actual process look like to get your company on Launch instead of DTM?<\/p>\n\n\n\n

Figure Out How You\u2019ll Roll Out<\/h2>\n\n\n\n

Does it make sense for your org to roll Launch out all at once to all of your properties? Or would you prefer to bite off one chunk at a time? (For instance, one client is currently updating their internal search single page app, so they\u2019re going to roll out Launch there first, as a sort of guinea pig.) Keep in mind that even if you are only rolling out Launch to 3 pages first, ANY roll out is going to have to tackle some global logic- it may be that those first three pages are the hardest because you\u2019ll need to tackle how to handle not just the requirements for those three pages, but also global items like authentication status or global marketing tags.
If you do want to roll out all at once, you can keep using the same DTM embed code<\/a> you always have so your developers don\u2019t need to make changes to the pages, but that\u2019s an all-or-nothing option (once you switch to Launch, Launch will \u201cown\u201d that embed code unless you choose to re-publish from DTM), and it only works in prod (dev\/staging environments will still need the new embed codes).<\/p>\n\n\n\n

Also, if you\u2019re considering having DTM and Launch run alongside each other on the same page<\/em>\u2026. don\u2019t even consider this an option. It won\u2019t work. Both tools use the _satellite object and one WILL overwrite the other and\/or get very confused by the presence of the other.<\/p>\n\n\n\n

Validation<\/h3>\n\n\n\n

Keep in mind the effort to validate things- even if you are doing a \u201csimple lift-and-shift\u201d, you will still need to validate that Launch is doing all the things that DTM had been doing<\/strong>. Depending on how well-documented your current implementation is, and\/or what QA efforts are currently in place, this may mean figuring out what it is that DTM is currently doing so you know whether Launch is matching it or not. This is a golden opportunity to set up some QA processes, if you haven\u2019t already.
If you don\u2019t have a solid process already in place, you won\u2019t be able to test every possible beacon for every possible user, but you should can set up a testing procedure in place for critical beacons on your most typical flows. Note, none of this is specific to DTM or Launch, but is a best practice regardless and will help with the DTM-to-Launch migration.<\/p>\n\n\n\n