DTM to Launch: Migration Project Overview
Two years ago, I wrote about Migrating from DTM to Adobe Experience Platform Launch — though we called it Launch, by Adobe at the time. When I wrote the article, I wanted you to:
- Know that you could re-use your DTM embed codes for Launch
- Understand that there are a few tools to help you move resources from DTM to Launch
- Give a very brief look at what a migration project could look like
Today, I want to revisit #3, but go into more depth. This article will be the first in a series that will look at project strategy, tactics, and some side-by-side comparisons of DTM and Launch.
Just a Library
Tag managers can do lots of things. Resource definition, governance, publishing, comparison, notifications, and much more are all on the menu of features that they may provide, but that is all on the periphery. At the core, the tag manager must produce a JavaScript file — commonly called a library — that will execute on your site.
Your site contains a <script> tag that loads this file when your customers/users look at your website in their browser. Those individual browsers will load this file and execute it.
In its purest form, the end-game of DTM to Launch migration is to have Launch produce this JavaScript library instead of DTM. And we should also make sure that the library is doing what we want it to.
Project Overview
With our project framed in this way, the steps become simple to define.
- Create/edit resources in Launch
- Build a library
- Test the library
- Promote the library
- Publish the library
There are plenty of opportunities to get lost along the way, and you will undoubtedly do so more than once over the life of your project. But I always find it helpful to keep the simple version in mind, so I know how whatever I’m doing right now fits into the overall plan.
Let’s talk about each step in a little more detail.
1. Create/edit resources in Launch
In Launch, the three resources that end up in compiled builds are extensions, data elements, and rules. Extensions fill the same role that tools fill in DTM — but extensions are much more powerful. Data elements behave almost identically between the two systems. Similar to extensions, rules fill the same role, but they’ve gained both flexibility and power.
There are many ways to create resources in Launch. As we get further along in the series, we’ll discuss the options and which ones make sense in your situation.
For now, the critical point this: migration is a choose-your-own-adventure scenario, and how you execute this step will depend on the choices you make.
The rest of the steps in the process will look remarkably similar, regardless of the choices you make.
2. Build a library
In DTM, any resources you created were automatically built into the stage environment. That was the only place to test that was available.
In Launch, you group resources together into libraries. These libraries are combined with anything that has been previously published or is on the production pipeline.
Once you’ve created the resources you need, you will put them into a library and build them in a development environment so that you can test them.
3. Test the library
Once your development library has been built, you need to test it. Your testing will likely reveal issues that you need to fix. In that case, make edits to your resources, do another build, and test again.
Testing is a rinse/repeat process of resource changes, builds, and tests until you get the behavior that you want. Everybody divides this up differently so that it works best for them, and that is perfectly fine. The amount of time spent in this step will vary greatly depending on the complexity of your site, library, and company standards for security and governance. Just know that extra time spent here is likely to save you headaches down the road.
4. Promote the library
Once you are satisfied with the changes made in the development environment, you must promote the library.
The first step is to Submit the library. This makes it available for deployment in the staging environment that comes with every property. This staging environment fills the same role as the staging environment in DTM.
In this stage, it is expected that you will deploy the library in your pre-prod environment that is the final testing state before changes are shipped to production. For larger customers, this is a critical step. For many smaller customers, they often just skip this step.
Once the library passes this step of testing, then the next step is to Approve the library. Once approved, the library waits in the approved state until it’s time to deploy it to production.
5. Publish the library
Publishing your Launch library is the final step in your migration project. As you use Launch day-to-day, this will eventually become routine, but this first time, it’s a big moment.
If you are re-using your DTM embed code, then this is the big moment. Once you push this button, your Launch library will replace the DTM library, and your migration is complete.
If you are planning on using Launch’s new embed code, then you will still Publish the library, but you will not actually be live with Launch until you update the embed code on your site.
Wrapping Up
At a high level, that’s the scope of the project.
- Create/edit resources in Launch
- Build a library
- Test the library
- Promote the library
- Publish the library
Step 1 will look different depending on the scenario you find yourself in. Steps 2–5 will look very similar for you regardless of how you do Step 1.
That means that the next things we need to discuss are the choices you face in Step 1 so we can figure out what you need to do there. The next few articles will cover the critical decisions you need to make and discuss the different migration paths available to you, depending on your choices.
Until next time, happy tagging =)
