How to Handle Master, Historical, & Transactional Data Ahead of a CloudSuite Implementation

The conversion scope and strategy that we decide on during a pre-planning engagement has a pretty big impact on the structure of the overall transition project, as does the work effort and direct cost for this implementation. Let's discuss how and what we focus on during this important phase in the pre-planning project, as well as what it means for your overall implementation.

There are three different kinds of data that we can talk about in terms of conversion: master data, transactional data, and historical data. Master data concerns vendors, items, HR organizational structures, and the chartered accounts, all of which obviously needs to be converted in CloudSuite. We can exclude inactive or obsolete master data, with the exception of any older master data that's still necessary because of the dependent historical data conversion. Ideally, you want to use the CloudSuite implementation as an opportunity to clean up and reorganize this master data, while also keeping in mind that all of it will need to be mapped back to the legacy system. As part of the project, we establish a crosswalk to identify the transformation component.

When it comes to master data, clients usually want to know the projected length of the design phase since financial structure master data in v10 is so different from CloudSuite. This phase is pretty similar to a net-new implementation in that there's some current-state analysis and some super-user training to help educate the power users on the functionality of the systems. After this step, we have a series of design workshops to create a future state design document. Typically, we see these as ten-to-fourteen week periods, although sometimes they can be scaled down more aggressively if there's a very simple footprint. However, if the organization is more complex or if you're bringing in multiple business units, these workshops can be extended.

Master data seems pretty straightforward, so let's talk a bit about transactional data. At the point of go-live, CloudSuite becomes the system of record on our operational system, which means we need to bring over any open transactions that are required for business continuity. We also need to think about procurement transactions and any open purchase orders that might not have been received or invoiced yet. This is data that we tend to want to minimize because of its complications. Because transactional data is a moving target, we won’t have that same set of open data throughout the test rounds that lead up to our CloudSuite going live.

To minimize the open transactional data, we recommend using blackout periods wherever it is practical or reasonable. This process is something that's more akin to a net new implementation where you don't bring over all that historical sub-system data. I know that Lawson customers are used to having a large amount of data come over because that was part of the upgrade process for ten, fifteen, twenty-five years. Yet in this situation, there's significant effort to map and bring that data over to make that transition possible. However, the value is generally not there.

It’s important to balance the impact on our business areas while changing systems because it’s always a challenge to switch between two different systems for an interim period. However, I’m not trying to minimize the amount of effort it takes to convert over all this data. It’s an expectation that must be managed within an organization, bringing us to the question of historical data. You need open data on day one of go-live, but depending on what business area we’re talking about, our business finds the realistic need to look at data going back three, five, maybe up to seven years. Many customers want to know if that data remains in the legacy system or do we convert it into CloudSuite – the answer is multi-faceted and there are pros and cons to both.

The right answer doesn't necessarily need to be the same for every functional area; as part of our pre-planning engagement, RPI will hold a conversion workshop and basically walk through all of the implications, gather feedback from the business leaders who will be impacted by these decisions, and really try to help an organization work through this decision-making process. Not only do we need to decide upon the scope of the historical data conversion, but we also need to think about where to put the data that's not getting converted. For example, if we're doing a CloudSuite implementation on a one-year timeline with a consolidated go-live, it's important to have an agreed-upon archiving strategy fairly early in the project.

Learn More about RPI Consultants

Back to Blog

Related Articles

What does an HCM data migration with Infor look like?

If you choose to embark on a data migration, that is something that you or your partner would...

Ensuring You Have Enough Time for Data Conversions

I’ve been working at RPI for the last three years, but I have 36 years of IT experience and...

Breaking Down the Data Validation Process

Following last week’s conversation around the timing of data conversions, let’s dive into the data...