Learn the step-by-step process involved in migrating from one MarTech solution to another in this white paper.

1. MASTER YOUR
MARTECH MIGRATION
A GUIDE FOR SWITCHING WEB-BASED
MARKETING AND ANALYTICS SOLUTIONS

2. 2
TABLE OF CONTENTS
Introduction
Overcoming Obstacles
The Migration: From Preparation to Completion
Pre-Migration: Getting Your Boss’s Blessing
Phase 1: Document
Phase 2: Strategize
Phase 3: Migrate
Phase 4: Test
0 3
0 4
0 7
0 8
1 0
1 3
1 5
2 4
2 7 Post-Migration: The Finish Line
0 5 The Development, Staging, Production Model

3. 3
INTRODUCTION
Whether you’re moving from one tag management system to
another, switching web analytics solutions, or adopting an alter-
native marketing technology for your website, it’s important to
know what steps will lead to a successful migration for any Mar-
Tech implementation.
As you work through your migration from preparation to comple-
tion, you will likely encounter several obstacles, ranging from get-
ting management approval for your migration to deciding on how
you will ensure accurate tag functionality during and following your
migration. At ObservePoint we’re here to help you navigate the ob-
stacles you’re confronted with during each step of your migration.
This white paper presents a 4-phased approach to completing a
successful MarTech migration. How much you utilize each step will
depend on the size and complexity of your migration, but regardless
of your migration size, all the concepts presented here will be useful
to consider.
Note: This guide is specifically focused on migrations of
marketing and analytics implementations that have some
reliance on JavaScript tags—the small snippets of code that
collect data from your website and transmit them to your
various marketing solutions. ObservePoint is especially
equipped to help with migrating such solutions, though this
guide is for ObservePoint and non-ObservePoint customers
alike. Enjoy!

4. 4
OVERCOMING OBSTACLES
As mentioned above, you will undoubtedly encoun-
ter obstacles as you transition through your MarTech
migration. However, many of the obstacles you face
in your migration process can be overcome through
the use of an automated tag governance solution,
like ObservePoint.
For example, you may experience difficulty when doc-
umenting your pre-migration tagging implementation,
especially if you are attempting to do so manually.
Documenting your pre-migration implementation
manually is extremely labor intensive and prone to
human errors.
Rather than attempting to manually document where
and how your implementation’s tags are deployed,
you can use the powerful automation of ObservePoint
to scan and document the existing tags you have
running on your site or app. You can then use this
pre-migration documentation as a reference point
when comparing your post-migration implementation,
which can also be created using ObservePoint scans.
Additionally, you may want to test potential new scripts
without having to edit the code on your page. With
ObservePoint’s Remote File Mapping functionality, you
can intercept requests for script files in production,
replace them with your test script, and then test your
new scripts in a production environment to make sure
your tags are accurately firing before editing anything
on your page.
Another hangup you may encounter is testing your
MarTech implementation for accuracy upon the
completion of your migration, as well as into the fu-
ture. To help with this hangup, ObservePoint allows
you to set up automated scans to periodically test
your implementation and ensure your tags are all
firing correctly. This is extremely beneficial when
testing your final implementation, and when work-
ing to maintain the integrity of your implementation
into the future as your website goes through period-
ic changes.

5. 5
A useful model for ensuring a well-functioning implementation is the development, staging, and production
model. This model is quite familiar to developers, but can also be incredibly useful to understand as a marketer
or digital analyst as well.
The development, staging, and production model consists of different environments along the web development
process. Starting with the development environment, each environment is used as a testing ground for the next
environment. In the context of MarTech migrations, the development and staging environments allow you to
test tags before going live.
THE DEVELOPMENT, STAGING,
PRODUCTION MODEL
The development environment is essentially your initial experimentation environment where you
can build up the minimum viable product of your website or app. In the development environment, your
website or app will be held on a private server (often your local machine), and only accessible to you and
your team. In this state your site or app is not visible to the public eye.
DEVELOPMENT ENVIRONMENT
The staging environment is where you prepare your site or app to be seen by the public.
The goal of the staging environment is to replicate the production environment as closely as possible. Think
of the staging environment as the final prototype of a product before releasing that product to the market.
Like the development environment, the staging environment still exists on a private server, which allows
you to adjust and test the complete version of your site without risking a publicly viewable malfunction. You
should conduct major testing and adjustments in your staging environment before going live to the public
in your production environment.
The production environment is the live version of your site, and is completely accessible to the public.
Any updates to your production environment should be tested in the staging environment first to ensure
functionality, unless you are using the ObservePoint Remote File Mapping feature, which allows you to
test new scripts and tags in ObservePoint scans/audits of your production environment without actually
changing those scripts and tags on your site. The Remote File Mapping feature is a great time saver when
you’re actively manipulating, testing, and replacing tags.
The initial setup of your environments can take a little work, but is well worth the effort. Once you have
done so, you’re ready to begin your migration.
STAGING ENVIRONMENT
PRODUCTION ENVIRONMENT

6. 6
First, let’s address a pre-migration, non-technical challenge you will likely face when preparing for the switch:
getting buy-in from your boss (or your boss’s boss).
THE MIGRATION
from preparation to completion

7. 7
Getting your boss’s blessing will be important if your migration
demands a significant amount of time and resources. If your
project meets this description, read on.
Accurately communicating the importance of your Mar-
Tech migration to managers is a crucial step to ensuring
a successful migration, especially since managers often
overlook or don’t understand the value in optimizing
your MarTech solutions. Consequently, you’ll need to put
together a business case to convince managers that the
time and resources spent on your migration is worth it.
Here are some items you should include:
PRE-MIGRATION
getting your boss’s blessing
First of all, you need to explain why you’re carrying
out this project, which may be obvious to you, but not
necessarily to your boss.
Some objectives of the migration you could bring up
when persuading your boss include:
Improved cost structure
Increased efficiency associated with
adopting or switching MarTech solutions
Features that are more in line with your
specific business needs
PURPOSE (WHY?)
PERSONNEL (WHO?)
You need to tell your boss who will be involved
and what each person will contribute.
Some companies have a dedicated marketing technology
team. Yours might not. The people and teams involved in
your migration will depend entirely on how your company
manages marketing technologies.
When writing and presenting your business case, make
sure to outline specifically who will be involved in the
migration. Doing so is especially important when you
don’t have a team dedicated to marketing and analytics
technologies and you have to get help from other teams.
Include the following:
TIMELINES (WHEN?)
When outlining your timelines, try to be as specific
as possible. You can use the following phases below
as a template together with the specifics of your own
implementation for structuring your project timelines.
Now that we’ve addressed getting buy-in from the
boss, let’s talk about the actual steps involved in your
migration.
What they will contribute
What percent of their time each staff member
will have to spend on the project each week
How long you estimate the project will take
for that individual
Who will be involved

8. 8
The goal of a successful migration from one solution to another is to, at a minimum, maintain the status quo
while making the desired improvements.
Because the main goal is to maintain the status quo, you will need to establish a baseline (a snapshot or
some form of documentation of your current tagging implementation) to check against as you create your
new implementation. There are a couple ways to create this documentation: manually or via automation.
If you’re approaching the Document phase manually, then make sure to factor in time for building thorough
documentation of what you have deployed on your website or app. This documentation will take time. If time
isn’t on your side, or you’re aiming for efficiency, automation can speed up the process.
As an alternative to manually documenting the technologies on your site, you can use an automated solution
like ObservePoint. ObservePoint’s software can conduct a comprehensive scan of your website, creating a
record of all technologies on your website. Here is an example report for a single page:
MANUALLY
VIA AUTOMATION
PHASE 1: DOCUMENT

9. 9
ObservePoint’s scans (known as Web Audits) can quickly create an up-to-date catalog of your legacy implementation
to compare against your Adobe Launch implementation. As a result, you can incrementally migrate over to Launch
and compare each step of the way.
Some of the benefits of using automation include the following:
Speed - Automated scanning software can audit and catalog much faster than any human—
at least 5 times faster for a scan of 100 pages. In all likelihood, you will have to scan more
than 100 pages, in which case automation is even faster.
Currency - Documentation of your tagging plan quickly becomes outdated, so if you have to
make any updates to your legacy implementation during your migration, you will also have to
update your documentation. Automated solutions, however, can run scans frequently, giving
you an up-to-date catalog of what you have on your site.
Accuracy - If tasked with manually scanning through an implementation and cataloging
all technologies on a site, a human is bound to make some mistakes. Automated solutions
minimize errors by carrying out a repeatable process that doesn’t miss technologies.

10. 10
At this phase of the migration, you will want to evaluate
what about your MarTech’s tagging strategy you want
to change and what you want to stay the same. There
are multiple (and likely better ways) you can deploy
your solution’s tags on your site, so you should evaluate
whether another strategy would serve you better in the
long term.
One of the most important parts of the Strategize
phase is to plan how you’re going to test your imple-
mentation to make sure everything is deployed correct-
ly. If you successfully carried out the Catalog phase, you
should already have a record of everything you need to
test. The question that remains is, “How will you test?”
Manual testing is possible using tools like tag debuggers,
Charles, Fiddler, or the developer tools in your browser,
but these options are highly manual and prone to hu-
man error. Automation is much quicker, more accurate,
and more enjoyable.
ObservePoint’s automated solution allows users to set
up scans of their implementation with rule-based test-
ing that reports when the data being collected doesn’t
match expectations or when tags aren’t present. With
specific ObservePoint features, users can use their
existing portfolio of tests or they can generate new
tests in order to verify that their new implementation is
functioning as expected. These features include:
PHASE 2: STRATEGIZE
PLAN YOUR TESTING QA STRATEGY
Remote File Map (RFM), which enables users to
locally test new scripts (like tag management scripts)
in place of old scripts in a production environment to
verify that tags are firing as expected. The key benefit
to utilizing RFM is helping you ensure tagging accura-
cy before actually deploying your new tags. Overall,
RFM is extremely beneficial any time you’re replacing
JavaScript libraries.
Web Audits, which enable users to audit their imple-
mentation in development and staging environments
before pushing live to production.
Tag Hierarchy, which, in the case of tag manage-
ment migrations, enables users to determine which
tags are deployed outside their TMS and migrate
those into their new TMS.
Validation Plan, which enables users to
automatically generate thousands of testing
conditions using their existing implementation as a
baseline, and then apply those rules against their
new implementation.
Together with manual solutions like ObservePoint’s
TagDebugger to spot-check individual pages as neces-
sary, ObservePoint will make it possible for you to easily
verify that tags are firing as expected.

11. 11
Once you have a baseline to work from (either from static documentation or from periodic audits of your site) and
have decided on your migration/testing strategy, you can begin migrating technologies over to the new version of
your site.
In some cases you may decide to start from scratch with your implementation. If you do so, you will be able to
resolve old errors and upgrade to new methodologies. But be prepared to spend a significant amount of time
making the migration. You will likely find some skeletons in the closet and unexpected challenges you will need to
address. However, at the tail end of the process, your implementation will be much better off.
PHASE 3: MIGRATE
The migration process will look different depending on the size and scope of your overall migration. As you migrate,
here are some things to consider:
Do you have any outdated tags that you should update or sunset?
Do you need to update your naming conventions to be more easily understood?
Do you need to update your data layer?

12. 12
Testing will be the final step in the migration process,
though you should perform incremental tests every time
you manipulate your tags.
The essence of testing is comparison, whether you’re
comparing your new implementation against documen-
tation or your production environment. Your options for
testing are either manual or automated, depending on
the resources you have available and the complexity of
your implementation.
When testing, you will want to prioritize the most import-
ant parts of your site relative to the marketing/analytics
technology. Some of the most important sections of your
site that you will almost always want to test during a
web-based MarTech migration are the following:
PHASE 4: TEST
If your site has a booking, shopping, or other important
conversion path influenced by the MarTech solution of
concern, you will want to focus a portion of your testing
on those paths.
Conversion paths are action-oriented, as are the tag
triggers along these paths. You will want to replicate the
actions of each conversion path under as many circum-
stances as possible, in which case automation will be
your best friend.
ObservePoint’s Web Journeys can replicate various user
actions, like clicking, inputting data into a text field, check-
ing a box, and more, while also testing for expected tags
to fire with each action.
You will also want to test your most important pages
where the MarTech solution of interest is deployed
to make sure the technology is working properly. For
high-traffic pages, having a tag go down for even a
short window of time can have a significant effect on
data collection.
ObservePoint’s Web Audits can run frequent scans of
your top pages, perform actions on each page, and
even wait for time-based triggers to fire in order to
verify that all tags are firing as expected.
Many analytics and marketing solutions rely on the
data within the data layer object. As you test, you
should verify that the data in your data layer matches
your standard formatting conventions. ObservePoint’s
Data Layer Validation feature can help you test the
data layer across your website.
Ideally you will carry out these tests in your develop-
ment and staging environments before pushing live
to production, or by using a Remote File Map feature
to locally switch out scripts during a test. Doing so will
make finding errors easier and relieve the stress of
pushing your new implementation into production.
CRITICAL CONVERSATION PATHS
TOP PAGES
DATA LAYER

13. 13
POST MIGRATION
the finish line
S C H E D U L E A D E M O
After your final testing phase, your MarTech migration will be complete, and you can congratulate yourself on a job
well-done.
ObservePoint is here to help you make it to the post-migration phase as quickly as possible. To learn more about how
ObservePoint’s automated testing and governance technology can simplify the next few months and beyond, schedule a
demo.