DTM to Launch: Migration Decisions and Options

There’s a classic model for project management that dates back to the 1950s. While different words get used for the various points of the triangle, the basic concepts remain the same: scope, cost, and time act as three constraints on a project’s quality. You can trade between the constraints, but they must remain in balance or quality will suffer.

The triple-constraint must remain balanced or you pay the price in quality.

A few unfortunately familiar examples:

• If a project has a specific deadline for completion, then ideally, you need to cut scope or pay more for it — often in the form of assigning more resources to the project. If you can’t balance the timeline with scope or cost, then you pay for it with quality.
• If you add scope to a project, then you must also adjust your delivery timelines or pay more for it — again, probably in the form of assigning resources. And again, if you don’t balance this well, your quality decreases.

There’s a more modern formulation of the project management triangle that simplifies things a bit. This version treats quality as part of the scope and makes it easier to ask the critical question

You can have your project good, fast, or cheap, but you can only pick two. Which two do you pick?

There is no option for good, cheap, and fast.

1. Cheap + Fast = less work. The work will be limited in scope, and you will need to keep a close eye on project quality.
2. Good + Cheap = takes some time. The project is going to take a while, so plan and set expectations accordingly.
3. Good + Fast = expensive. This one is going to cost you.

Cheap + Fast

Note: this is your fair warning that what follows through the rest of this post is a gratuitous oversimplification. I did it on purpose to draw some specific boundaries and display some clear options. Think of these as outlines that you will use to fully define your project rather than specific rules you must follow.

Picking Cheap + Fast leaves you out of the Good area.

Last week, we talked about how the ultimate goal of our project is to replace the library files from DTM with ones that were created by Launch.

If you find yourself in the cheap and fast scenario, you’re probably doing the project with existing resources, you’re looking to move as quickly as possible, and you’re willing to make some sacrifices. These sacrifices will likely manifest in a messier Launch implementation, slower on-page performance, and some optimizations that you won’t have time to include.

Option 1: Use the Upgrade Assistant

DTM has an “Upgrade to Launch” button on the Dashboard page for each property. You are probably going to want to click this button. And for the absolute smallest amount of work, you’re also going to want to check the option to link the DTM embed code.

The Upgrade Assistant will create a Launch property that mimics your DTM property — as carefully as possible. The assistant copies any enabled resources into this new Launch property. Some DTM resources do not have a Launch equivalent, but anything that does will go. For details on exactly what will and won’t go, see the Upgrade Preparation Guide.

One specific callout here is the Target tool. DTM’s Target tool deploys the mbox.js JavaScript library for Target implementations. The Target extensions in Launch use at.js (v1.x or 2.x depending on your choice), and we cannot automate migrations between these two approaches. So you’ll have to implement Target as a separate step once you have your Launch property setup.

When you use the Upgrade Assistant, if you also check the box to migrate the embed code, then your Launch production environment becomes linked to DTM. When Launch publishes a library to the production environment, it will use the same name as the DTM production environment. Ultimately, if you check this box, you will not have to update the pages on your site to use a new Launch embed code, you can keep the DTM one. That also enables a simple emergency rollback option. For details on linking embed codes, check out the Link DTM embed code docs.

Check this box if you want to reuse your DTM embed code.

Once your new Launch property with the copied DTM resources is available, you’ll want to make a library and begin the test/tweak/build cycle as described in the Migration Project Overview.

When you have a library that meets your requirements, you’ll promote that library through to your Launch production environment. If you have linked your DTM embed code to Launch, clicking the Build & Publish to Production button in Launch is your final step.

If you reused your embed code, this is the Go Live! step.

Good + Cheap

Good + Cheap means you’re not optimizing for your project to get done quickly.

In the Good + Cheap scenario, we accept that we are going to take some extra time to perform the migration. But we should also probably answer the question: what does “good” mean?

That question deserves an article on its own, but we’ll provide a quick answer today and do the deep dive another time. For today’s purposes, a good Launch implementation:

1. is maintainable with neatly defined property boundaries, a good naming convention, and contains only the resources you need.
2. will maximize on-page performance with an async embed code and the smallest feasible library achieved through optimized rules, minimal use of custom code, and appropriate use of private extensions.
3. respects user consent by only collecting data for which the user has granted permission.
4. maximize the data you can collect through the usage of first-party domains for library loading and data collection.

There are valid reasons why one or more of the above do not make sense for your project. Consider this a non-exhaustive list of options you should keep in mind when defining the scope of your “good” implementation.

With the scope determined, there are two basic approaches to consider (numbered as #2 and #3 because #1 is above in the Cheap + Fast section).

Option 2: From Scratch

This option is to build everything from scratch in a new Launch property. You’ll want to audit the contents of your DTM property and (recommended) your site and so that you understand what all those tools, data elements, rules, and code are doing.

Then you make a new Launch property and create the resources you need to meet your requirements. Test and publish. Replace the embed codes on your site with the new Launch embed codes (preferably async ones).

Option 3: The Hybrid

Option 3 is a hybrid approach between 1 and 2. You’re still going to do your property and site audits, but you’re going to put in some effort in your DTM implementation to clean it up first. Enable — and maybe even update the names of — all the resources that you want to copy to Launch. Disable the resources you do not want to show up in Launch.

When you use the Upgrade Assistant now, only the specific resources you’ve marked for copying will move over. Once the assistant has completed this leaner Launch property, you can rollover to it and continue with whatever additional requirements you’ve included in your scope.

Good + Fast

If you pick Good + Fast, then cheap is not an option for you.

If you find yourself with unlimited resources (either people or cash), then you may want to look into this option. If it’s cash you have on hand, then you’ll probably want to look into some professional help.

Option 4: Spare No Expense

Option 4 still includes determining the scope of your “good” implementation, but instead of taking your time on the project to keep expenses done, you spend whatever is needed (in time or resources) to get it done fast.

You can talk to your Adobe account rep about Adobe’s consulting services, and we have a spectacular ecosystem of partners that have helped many customers with their migrations.

Either way, you come out the other side with a quick, thoughtful, clean Launch implementation that takes advantage of all the new performance and efficiency improvements.

Conclusion

You have a few different decisions to make in terms of the scope of your project and which constraints you choose. Depending on the choices you make, the overall shape of your project will look like one of the following:

1. Use the Upgrade Assistant — this is the Cheap + Fast option that you would select when moving your DTM implementation straight into Launch without doing any cleanup or optimizations.
2. From Scratch — this is the first of the Good + Cheap options where you are not copying any resources, but setting them up in Launch with a clean slate.
3. The Hybrid — this is the second of the Good + Cheap options where you clean up your DTM properties, make deliberate decisions about which resources to copy, and further optimize once you’re in Launch.
4. Spare No Expense — this is the Good + Fast option. Spend whatever it takes in resources and money to get your fully optimized project done quickly. You’ll probably get some professional help.

I said upfront that there would be gratuitous oversimplification, and I’m confident that I delivered that here. Every migration project will be unique because of company circumstances, resource constraints, and implementation complexity.

That said, this should still be a helpful guide as you navigate your migration from DTM to Launch.

Happy tagging =)