Our industry is undergoing some of the biggest changes in decades. Digital analytics has been a very stable industry branch to work in, with only incremental updates and releases disturbing the calm environment. If you learned how to create value with Google Analytics or Adobe Analytics 10 years ago, you would have a particularly good foundation to be able to create value until not very long ago. However, this stable period is now over.

In recent years, our beloved industry has been disrupted by several events. Google has famously sunset Universal Analytics in an effort to replace it with the skeleton that is Google Analytics 4. Adobe is creating some big commotion with Customer Journey Analytics, which brings some features that have previously been unknown to the Adobe world. And on top of this, smaller vendors like Amplitude are trying to get a slice of the cake and heavily promote their own tools. There’s never been as much competition and vendors on the market as today.

Companies try to navigate this changing landscape in vastly different ways. Some try to avoid any disruption to the business, while some others try to solve their long-standing pains by considering migrating to a new platform. A third group of companies is driven by FOMO and the attractive capabilities that other solutions promise.

Having worked in many industries and with many tools and vendors, I wanted to share my experience and explain what companies should look out for when considering a migration. After all, stability is a crucial success factor for any data-driven practice, so we should be careful to avoid mistakes when considering a new tool.

To start, let’s talk about the most important question of all in the first step of migrating to a new platform:

Should you migrate at all?

I know, I know. This question is the most boring one to ask. And yet, it is one that we like to struggle the most with. Before we can even start talking about the concrete steps we need to take to master a migration, getting the "Why" figured out is of highest importance.

One of the most common reasons I’ve heard sounds quite simple: Platform Y can do more than we can do in our current Platform X. And yet, there is much more nuance to this than we might realize. For example, we need to differentiate between things we can’t do because of real, technical limitations and a messed-up implementation.

With any new platform, we have the luxury of starting with a completely fresh implementation and without any legacy baggage to drag us down. It feels like a breeze of fresh air and the best way to finally fix all the small bugs and imperfections in our setup. But just as Jenn Kunz is teaching us, there is absolutely nothing stopping us from doing the exact same thing with our existing tool! If our implementation sucks and doing any analysis takes forever, blaming the tool won’t cut it. Even worse, if we can’t get it right the first time, we run a considerable risk of messing up the new tool in different ways!

Beyond the risk of using a bad implementation as an excuse for a new tool, we also need to be aware of the several types of digital analytics solutions on the market. In my recent post, I came up with this categorization of available tools:

‍

While you can check out the original post for the full explanation of the categories, the takeaway here is simple: When moving to a new platform, we should always try to increase at least one of the two dimensions (out-of-the-box value and customizability) while keeping the other one constant. Ideally, we strive to move to the upper-right corner.

It makes very little sense to even consider a migration within the same category of tools. When you are not satisfied with Amplitude, buying into Heap or Mixpanel will not save you. It also doesn’t matter if you waste your time with Fathom or Plausible, so making any change would be unjustified. In the same way, moving from Google’s Universal Analytics to GA4 drastically reduces your capabilities, so you should rather consider Piwik PRO or one of the Adobe solutions.

In the same way, moving from a custom-built data stack composed of BI tools into the Challengers category makes less sense than moving up to the Analytics Tools category. Generally, staying in the same category and moving towards the bottom or left of the chart should be avoided!

For this article, we’ll use two quite common examples: Moving from Google Analytics to Adobe Analytics and doing the same from Adobe Analytics to Adobe’s Customer Journey Analytics. The first step to any successful migration is to...

Step 1: Understand what and how you need to change 

Once it is decided that a tool migration is the best way to evolve your practice, you need to spend a considerable amount of time understanding how the new solution differs from the current one. Some tools come with a Tag Management System, others don’t. Adobe’s solutions offer ways to democratize data across the whole company, while Google Analytics encourages silos between marketing, analytics, and product teams. 

Some relevant points of change you should consider are: 

• Implementation: Does the new solution come with a Tag Management System? Can you continue to use your existing TMS? Do you need to change your data layer? 
• Administration: How are users managed? Who will manage users in the future? Can developers implement new features without the analytics team being involved? 
• Analysis workflows: Is the analytics team needed for every question the business might ask? How can stakeholders collaborate in the tool? At which level does the analytics team need to be involved? 
• New capabilities: How do newly available features change your overall tool setup? Which workflows does it allow that were previously impossible? 
• Lost capabilities: Which features will be lost after the migration? How do you plan to compensate for them? 

Let’s use a practical example for those questions. Imagine we are in the lucky position of migrating from Google Analytics to Adobe Analytics. In this case, we would be free to choose between keeping Google’s TMS in place or replacing it with Adobe Tags. If you are using an Event Driven Data Layer today, you probably don’t need to change it much, if at all. In the easiest case, you just bring the Adobe Analytics library into GTM, then modify your existing GA events to also send data to Adobe Analytics. Easy! 

In terms of user management, Adobe brings some neat opportunities for integrating with process management tools like Jira to manage users. While access can be governed by the analytics team, it might very well be completely automated. That part is not that different, too! 

Where it gets really interesting is when we look at the new workflow opportunities. Different from GA, AA allows for democratized insight generation across the whole company. While it is possible to keep stakeholders out of AA entirely, a mental shift towards democratization unlocks some real collaboration on data without the analytics team being involved. That’s a fundamental difference! The new capabilities further support this shift in mindset, as experimenting with attribution models is now in everyone’s grasp. 

Naturally, some things are not as easy in Adobe Analytics as they are in Google Analytics. One feature that many customers are missing is the integration with the rest of the Google universe, like Google Ads or Search Console. It takes a bit of time for them to discover that AA’s Data Sources feature can bring exactly that and many more data points, especially when used with a platform like Accutics Connect. With just a bit of integration work, the amount of available data quickly tops what you know from GA. 

While this migration from Google Analytics to Adobe Analytics is quite common, there are some new migration options that stem from the release of Adobe’s Customer Journey Analytics. So, how would such a migration look like? 

A customer moving from Adobe Analytics to Customer Journey Analytics can, of course, build on the existing foundation of the current setup. The tag manager, data layer, user management, and workflows can largely stay the same. Some work might be needed for mobile apps, but the overall effort is surprisingly low on the frontend side. 

Where it gets a bit more interesting is with the administration tasks. Report Suites, metrics and dimensions, and the overall data structure work quite a bit differently in CJA. As many of the legacy limitations don’t matter anymore, we are now free to think in a more liberal way about our data structures, meta data, and integrations. Beyond the digital channel, we can use CJA in a much larger scope for all data a company might have. Of course, if you have been managing the Adobe Analytics instance before, you might have to work with some very unfamiliar data sets and structures. Bringing CRM use cases into the tool is exciting but requires a lot of cross-company collaboration. 

With CJA being a much younger tool, migrating from AA today would mean compromising on a couple of fronts. For example, Report Builder works quite a bit differently. Data Warehouse is not supported in the same way, and Data Feeds don’t exist yet. The same goes for Real Time Reports. While Adobe is working on those, you may need to come up with a solution for those missing parts. 

Another example of a substantial potential for improvement is in regard to your marketing tracking practice. With tools like Adobe Analytics or Customer Journey Analytics, you get the chance to adopt some mature processes to track marketing traffic and bring metrics together in completely new ways. You don’t need to pollute your marketing URLs with many UTMs to identify traffic sources but have Classifications as a powerful way to translate random tracking codes into any meta data you could ever want. Using a tool like Accutics Standardize, you are able to provide better, governed marketing data while also providing capabilities to create short URLs, QR codes, and much more. 

Analyzing how the new platform of choice differs from what you have today is crucial for any successful migration.

Once the capabilities are understood well, the next step is to... 

Step 2: Create a migration timeline 

This step is quite straightforward. Now that you know which areas of your business you might need to touch, you should put the migration onto a timeline and plan your own and related activities accordingly. 

Besides possibly outside factors, like an expiring tool license, there are many internal factors that might dictate a migration timeline. For example, a company might have a strict release schedule for frontend changes in apps and websites. If you don’t have a data layer in place, migrating those websites can be a considerable effort. 

Another complicating factor is the number of apps, websites, and other platforms that need to be moved. A migration might take considerably longer if a company entertains many, smaller websites than if they were using a single, large platform. Media companies are especially common to run many targeted platforms, which can complicate a migration project. 

Depending on the company’s organizational structure, it is important to also consider the stakeholders behind those platforms. Instead of working through all websites in random order, it might make sense to prioritize all platforms belonging to a certain team, so you can onboard that team on the new tool in one swoop. 

To come back to our examples, a migration from Google to the Adobe world will naturally be a bigger effort than moving from Adobe Analytics to Adobe Customer Journey Analytics. For the former, you may want to switch out your full Tag Manager, the reporting tool itself, and potentially connected tools like Big Query or Looker Studio. For the latter, the TMS can stay the same, and you could even leave AA in place as the data collection tool, let alone the very low effort of required user training. 

Many companies like to use the momentum of a tool migration to elevate their marketing analytics capabilities. I already mentioned the potential to leverage Classifications to provide meta data, but that’s not where it has to stop. You can consider tools like Accutics Standardize to allow your marketing team to collaborate on centrally governed standards or Accutics Validate to ensure the standards are followed globally. 

During the migration period, some companies like to track data into both tools at the same time. While I personally don’t promote that approach too much, it can make sense for initial validation. One neat feature of a platform like Adobe Analytics is the option to bring in historical data from the old platform. If you want, you can very easily bring your old Google Analytics data with you to ease the onboarding for new stakeholders. How cool is that! 

Wherever you can, helping your users to get started will pay out massively further down the road. Preparation is key if you want to stick to your timeline, which is why I recommend to... 

Step 3: Set the backend up first 

It sounds trivial to point out, but you would be surprised how many analytics teams are trying to onboard their users onto a tool that has not been fully set up yet. Again, we need to remind ourselves that stability is critical when we try to establish a mature analytics practice. 

Setting up the backend naturally includes the data structures and general admin setup that is needed to even begin capturing any data. In Adobe Analytics, we need to create and configure a Report Suite to hold our data, together with all the required custom dimensions and events. 

However, the setup should go far beyond that basic configuration. For example, think about user groups, access management, and the processes involved in that. Those need to be in place before you should even onboard your very first user. If someone in IT or marketing needs to learn how to grant access, they should learn it before people come banging down their door. 

The same applies to the way we set up the foundation for our implementations. For example, an implementation framework can help to align websites and apps with a common standard, enabling collaboration and sharing of data. There is nothing worse than a rushed backend setup, as its poor decisions will have ripple effects for many years to come. 

In the Adobe world, a very valuable consideration is to leverage templates in Analysis Workspace to give users a starting point when diving into analytics. Especially when you are migrating from another platform, there is a big opportunity to rebuild familiar reports and dashboards as templates before onboarding any users. 

Customers moving from Adobe Analytics to Customer Journey Analytics will have to explore the new capabilities to re-process data on the fly, aggregate multiple Report Suites or even offline sources, and leverage SQL-based enrichment in Query Service. Features like Derived Fields can be a game changer for some companies, making it even more important to get the backend setup right first. 

With the right backend in place, I like to then get busy and... 

Step 4: Onboard and train your users 

Again, the order of steps might be surprising. If you take a peek at the next step, you will see that we haven’t even started implementing the tool yet. Why would we start onboarding and training users with practically no data? 

Once more, the reason is stability. It takes a considerable amount of time to teach an organization to learn any analytics tool, let alone teach them to expand on what they’ve already learned and acquire the skills for a different tool. There is nothing worse than having to learn a tool in a hurry because the old one is soon to be sunset. 

Besides the obligation of giving your company a fair chance of getting acquainted with the new software, it is also an effective way to build trust in the new platform and its capabilities. If you manage to engage your stakeholders from the very beginning and get them excited about being able to use it, it will make it substantially easier to get the right priority for any development tickets you may need to issue.  

For example, if you are moving from Google Analytics to Adobe Analytics (or even Customer Journey Analytics) you will have to break the expectation that might stem from the GA past. Where GA can only cover some surface-level self-service in the user interface, Adobe’s Analysis Workspace unites reporting, dashboarding, and exploratory deep-dives in the same interface. Because of this fundamental difference, there is no need for your stakeholders to wait for an analyst to spoon-feed them reports, as long as the analytics team has built the right environment that allows for complete self-service. 

This first enablement push is also a great way to collect early feedback on your implementation and democratization strategy. The trainer should continuously ask questions like “have we named this dimension right?” or “does this concept make sense to you?” during any session. If not, you either need to adapt your training or even make changes to your implementation strategy. 

User training and onboarding is one of the most important activities for any analytics team, so you should plan from the start to spend considerable time on more than one training course per future user.

After your new tool and data collection are ready for prime time, you should plan to repeat your enablement sessions and show your stakeholders how to apply their existing knowledge, this time with real data from their precious platforms and the production setup. This will also help you to resist the temptation of making last-minute changes to your setup, as you are urged to keep the promise to your stakeholders and give them what they expect. 

Beyond the required training for the new analytics platform, expanding your capabilities to enhance the quality of your marketing data will also mean that you will have to train your users on Accutics Standardize or Accutics Validate. In both cases, working with the vendor of your new toolstack can make it easier to focus on the most important parts and even provide additional scale. 

Naturally, before you can give your stakeholders that training on production data, you first need to actually... 

Step 5: Implement the new solution 

I know, this will come as a massive surprise to anyone reading this. If you want to use your new, shiny tool, you will have to implement it! 

Joking aside, this step is, of course, one of the most crucial, long-term important milestones on any migration roadmap. Hopefully, steps 1 and 2 will have given you a good idea of the actual work that needs to be done for this fifth step.  

To stay with our examples from above: If you are making the move from Google Analytics to Adobe Analytics, you may want to switch out your Tag Management System from GTM to Adobe Tags. Doing so will have a number of follow-up tasks for your developers, beyond just replacing a single line of code. While the GTM-style data layer can be replicated in Adobe’s Client Data Layer Tags Extension, you may need to fine-tune some specific functionality to be fully feature-complete. 

Making this scenario even more complicated, some companies are still not using a TMS to manage their marketing tools and do not have a data layer in place. In those cases, the effort to make any migration will be considerable and cumbersome. Companies like that should take the chance to adopt modern standards, like the mentioned TMSs and data layers, so they free themselves from the need to run every change request through the development team. 

Even if you are already part of the glorious world of Adobe’s analytics solutions, migrating from Adobe Analytics to Customer Journey Analytics will bring some work to your teams. Hoping that you are already using Adobe Tags and a data layer, the actual effort to modify your Rules and Actions in Tags highly depends on your general implementation style. 

For example, you could set up your implementation to send hundreds of different data layer events, depending on how the user has interacted with the page. As a result, you will have to migrate hundreds of Rules in Adobe Tags to switch from the Adobe Analytics Extension to the modern Web SDK Extension. On the other hand, if you had the foresight to use an implementation framework, your effort will be significantly lower. Moving a dozen Rules to the new Extension is an annoying one-time effort, but it won’t keep you busy for weeks. 

Tag Managers, data layers, and implementation frameworks are the biggest time-savers for any migration project, but that’s not where it stops. They also help to reduce day-to-day maintenance during normal operations and make your implementation easy to understand and maintain. If you are not using them today, bringing them to your platforms will bring massive benefits and skyrocket your maturity level, even if you are not planning for a migration any time soon. 

In terms of managing the actual rollout, you should of course first have all the TMS setup ready before placing the TMS on your pages. Some companies like to first deploy an empty container and add functionality over the course of the migration, but I’ve personally never seen a real benefit to that. Quite the contrary, following this approach will prevent your developers from being able to play around with the new features and see how they work on the page. 

Developer training and documentation are another important aspect of any migration. There are countless implementations out there that could only be understood by that one team member who left the company years ago without any documentation. That’s not good, and you need to actively work against that happening to you. 

Another crucial step is to enable your stakeholders to easily debug your implementation. I’m not suggesting that they should get to the level of an implementation specialist or developer, but being able to quickly test if a requirement has been fulfilled correctly is a necessary skill. Depending on how you craft your implementation, this will either require hours of training and numerous browser extensions, or just take a couple of minutes and no other tools beyond the browser.  

Re-implementing an analytics tool is a fantastic opportunity to bridge historical gaps between stakeholders, developers, and the analytics team. When defining requirements, the stakeholders should be put in the driver seat and learn how to formulate them according to the implementation framework. It should be easy for them to later validate if everything works as requested and report any discrepancies to the developers and analytics team.  

With this last point, we’ve already started to dive into the final step of the migration, which is to... 

‍

Step 6: Uplevel your analytics practice 

Now that you are up and running with your new tool, the time has come to take an honest look at how you and your company are working with and thinking about analytics today. Your new setup likely has some enormous potential to enable new stakeholders to work with data in more powerful ways than ever. What does that mean to you? 

Traditionally, analysts have been needed to extract data from the analytics system, aggregate it as needed, and sometimes even search for “insights” and present them to stakeholders. With a tool like Google Analytics, that practice is still needed today. But in the Adobe world, allowing stakeholders to work with data on their own is the best way to create value out of data. 

In the Adobe world, allowing stakeholders to work with data on their own is the best way to create value out of data.

In a similar way, an implementation framework helps you to stay out of the implementation process entirely! With just a bit of documentation and some first guided implementation tickets, you can enable your stakeholders to work directly with developers on tracking new features and pages, without any need to involve you. This drastically shortens implementation times and overhead while still providing high quality data. 

With reporting, analysis, and even implementation now in the capable hands of your stakeholders, the analytics team can now focus on driving adoption and enhancing the existing frameworks where necessary.  

Another important aspect of working in such a modern analytics team is providing continuous support and enablement during your stakeholders' daily operations. I’m personally a big fan of open channels in Microsoft Teams where stakeholders can discuss all things analytics, from implementation to analysis and presentation, both amongst themselves and with the analytics team. After all, we usually have some clever ideas to contribute and can connect the right stakeholders to provide additional input or context. 

In a company like this, you have a buzzing analytics community and many active monthly users of the analytics solution. The analytics team does not burn themselves out by giving “recommendations” to stakeholders who will ignore them or reporting the same performance numbers over and over again. Once you have seen this work in practice, you will be changed forever and find yourself turned off by the old practice we’ve all been following for a long time. 

About Frederik Werner:

‍Frederik Werner is Head of Analytics at Accutics. He is the author behind Full Stack Analyst and has quickly been recognized as one of the top bloggers on Adobe Analytics and the latest trends in web analytics.

‍