By Nigel Hunter
Migrating your product, category and customer data may be the most overlooked aspect when replatforming your ecommerce system landscape. If you’re replatforming from a monolithic to a composable landscape, it’s essential that you prioritise your data. When thinking about data, consideration is needed on where your data is today, what you’re using that data for, where you’re going with that data, what data you’re aiming to use going forward, and where you’re going to get that data from. Additionally, you need to think about the quality of your data, doing a blanket migration isn’t always appropriate.
It’s a lot to consider and the general principal is to migrate as much as possible! However accurate data is essential when scaling a business and if you want to keep your data when you replatform then you need to ensure you know all the different types of data you’re currently using and how it transfers going forwards.
It’s imperative to ensure that while migrating from monolithic to composable you don’t lose good quality data and that once migrated you make better use of the data to improve operational efficiency. These will help you to see faster growth and scalability from that composable platform shift.
Data Lakes & CDP
So, firstly, where are you going with your data? If you were previously on a monolithic platform, you potentially had all of your data in one place which you could then draw out at will. However, moving to composable, it’s likely you will have various systems, each of which could be storing data. To put it simply, from an operational perspective, it means that your employees could now be getting their data from multiple systems, which can introduce inefficiency. One way to combat this is to introduce a centralised data storage, such as a data lake or CDP as part of the migration activity.
If you don’t already have such centralised data storage, this should be one of your first considerations when going composable.
But what are Data Lakes and CDPs? And how do they help you?
Data Lakes can ingest vast quantities of data from a variety of sources. Just like water entering a lake from rainfall, data enters a Data Lake in its “natural” state and retains whatever structure it had in its original location. Data Lakes do not impose standardized structures on the data they store, but they do often add meta tags and identifiers to incoming data to aid in future analysis. The sheer volume and variety of information in Data Lakes make them powerful tools that allow you to centralise all of your data, however, their structure also renders them too unwieldy for your go-to-market teams like sales and marketing. They typically need a data analyst/scientist to make sense of the data for the business.
This is where CDP comes in, within a CDP data is also constantly being ingested, however they typically contain automated rules that can check quality, combine data from various sources, and structure in a way that can be consumed by business teams and made ready for other systems. Your go-to-market teams will depend on this up-to-date, unified, and immediately actionable data to drive personalized interactions. This is a CDP’s primary deliverable and the reason why non-technical stakeholders are the primary users of a CDP.
This sounds like it could be a lot of effort to create a solution for a problem you probably didn’t have to consider in your current world, however, it’s important to realise the benefits of a composable approach not just in gaining best of breed capability but also more granular data. Having more granular data spread across various systems adds the extra consideration of how you are going to bring this data together to make best use of it, to support the ability to scale faster. This also benefits the company in making better use of the data you gather in operational activities. With all of this centralised, detailed data, you’re then empowered to progress further into your composable journey.
The Data Layer
So, you have considered what data you need as part of your re-platforming and the options for centralising the extensive amount of data you will be collecting. However, is that everything? As part of any re-platforming activity, consideration is also needed for the detailed behavioural data that can be gathered as your customers navigate your website. This data is stored in Data Layers. Data Layers hold specific data, such as product, add to cart, remove from cart, checkout amongst various others. Data captured in the Data Layers can be fed to various Analytics tools.
That granular information from your website helps you draw out the event-based information that you need to fuel your own growth.
Avoiding Common Pitfalls
So, if you know where your data is going, what you’re going to do with it and where you’re going to get it from, then you also need to make sure you don’t lose any of your old data as you migrate and make sure you’re aware of the common pain points merchants struggle with when migrating their data.
Firstly, compatibility, when migrating data from your old systems to your new platform, you need to consider whether there’s any transformation needed. Also, once migrated, your new systems are likely to have to communicate with other existing internal or external systems. As part of your overall strategy, you need to ensure data can continue to pass between all systems, new and existing. Your overall data migration plan must also include time for testing that all system capability continues to function.
Secondly, data cleansing, migrating data that is poor quality just transfers the problem to your new systems. You need to take time to verify the quality of your data and potentially improve its quality before you start the data migration process.
Thirdly, volume of data, often organisations don’t plan enough time to migrate data from one system to another. Often the only option is to do it in batches, which takes time and isn’t something that happens at the point of switching over to your new composable systems. Planning is key, as your existing system continues to gather new data, such as new customer registrations/updates to existing customers etc.
Fourthly, maintaining your Search Engine Results Page (SERP) position, having a new composable Commerce system landscape is all well and good, but if your customers can’t easily find you using a search engine, traffic to your site can significantly decline post re-platforming. Areas to think about are URL structure, changing your sitemap and your robots.txt file to reflect your new platform structure.
These are just a couple of examples of common issues. A poorly handled transfer could cause any number of issues such as Incorrect product mapping and data, product images, customer data amongst other. These can cause issues with customer’s being able to access legacy data such as order history or your Customer Services team being able to manage customer contact efficiently.
Key Takeaway
As stated above, data migration is often overlooked as part of plans for a platform migration, but it’s essential for a business to be thinking about how it migrates its data before it even begins the re–platforming process. As part and parcel of an organisations thinking they need to make sure they consider, where their data is, where it’s going and how it’s going to get there as part of any successful re-platforming.
So, there’s a lot to consider but the important takeaway is, don’t forget the data! Successful composable journeys are almost entirely data driven so it’s important to be in the right mindset from day one.
Need help considering your data? Get in touch with Ayata today.