Data Migration Challenges in ERP Projects

The Importance of Data Migration for the Success of an ERP Project 

In project management, particularly in information systems, choosing an appropriate methodology is absolutely essential. This is even more true for an ERP project. Generally, the classic V-model methodology is chosen.

These phases allow for the establishment of a structuring milestone to overcome most problems, and are particularly well-suited for ERP projects. However, in parallel with these phases, there are other activities essential to a project’s success, such as change management, documentation, steering, etc. And among these parallel activities is the topic that interests us today: Data Migration.

This activity is, in reality, a complete project in itself. Broadly speaking, data migration includes the following activities:

It is a fundamental task as it begins in the Design phase and extends beyond go-live. Unfortunately, this activity is often relegated to the background because it is not considered a priority. This is clearly a mistake because it is a truly time-consuming task. It must therefore be initiated as early as possible to avoid finding oneself in an inextricable situation at the end of the project when time is short…

Here, we propose a list of best practices that can be applied to every project.

#1 – Data Transversality in an ERP Project

MeltOne pays particular attention to data migration, and this is reflected in our project management approach.

Let’s take the example of a structuring data element in a logistics project: the Material Master. In a context where SAP’s purchasing and sales logistics modules are used, material data constitutes the true functional core of the solution. This is where the specificities of each product are concentrated. It includes general product data (descriptions, weight, storage conditions, etc.), financial data (applicable VAT rate on sales, accounting and valuation data, etc.), planning data (lead time, lot size, safety stock, etc.), and data related to quality, warehousing, manufacturing, cost calculation, etc. Ultimately, this data comes from all company functions, and all SAP functionalities that impact products are represented in the Material Master data.

MeltOne recommends dedicated migration workshops with each department from the start of the project to identify data-related complexities (where, who, how). The objective is to highlight the interdependencies that may exist between different functional areas. A cross-functional vision across all business lines is essential. Not only for a good understanding of migration challenges and the definition of a data takeover strategy, but also for identifying the right business rules and, ultimately, for the overall success of an ERP project.

In fact, a successful migration requires the involvement of management from both the project and business sides. If this involvement is lacking, due to poor prioritization or underestimation of the workload, it can be very critical for the project.

2 – The Complexity of Migration

Depending on the SAP projects, the data to be migrated is not the same. The complexity of migration therefore varies from one project to another depending on the scope to be covered. To evaluate this complexity, it is useful to represent each data element as a component of a hierarchy ranging from the simplest to the most complex.

Let’s start with the simplest: master data. This includes basic information that changes little, such as a supplier’s address, packaging dimensions, etc. The Material Master is an example of master data among others (such as Vendor Master, Cost Centers, Chart of Accounts, etc.).

As soon as these elements are aggregated together within a larger level, for example by grouping several items in a Bill of Material, the complexity increases, and the dependencies that may exist between the different functional areas are strengthened.

Above that, we find transactional data. This corresponds to data that is cross-functional to several SAP modules and is by nature more exposed to changes. Transactional data includes, for example, the takeover of inventory, purchase orders, open sales orders, GL balances, asset transfers, etc.

The migration of purchase orders requires that dependent data from several modules be created beforehand, such as materials, vendors, accounting data (cost center, internal order, general ledger accounts, material groups, etc.). This is why a successful migration must strictly adhere to a sequencing of migration objects.

In addition to this cross-functional aspect of transactional data, there is significant variability. This data has a life of its own; an open purchase order has a history of deliveries or payments already made that must also be taken into account in the migration (partial payment/delivery).

MeltOne recommends limiting the volume of transactional data to be migrated as much as possible. Indeed, rather than undertaking the arduous task of migrating numerous open purchase orders, it is often more efficient to exclude them from the migration scope, for example by coordinating with suppliers to deliver earlier and by paying outstanding invoices before Go-Live. The idea is to minimize tedious reconciliation work.

Another example of transactional data is inventory migration. This is a critical migration object; an error in the inventory takeover (quantity, price) has a direct impact on the valuation of inventory in accounting. To minimize the risk of error without completely interrupting daily activities, a good practice is to somewhat restrict inventory movements over a given period (an inventory “freeze” period), and to use this time to conduct a physical inventory in the warehouse. Once the snapshot of inventory levels is obtained, the migration can be carried out based on a reliable representation of reality.

Thus, anticipating the Go-Live by all company teams is always very beneficial for the smooth running of an ERP project.

3 – Migration is an Iterative Process

Another pitfall to avoid is thinking that a migration file must be perfect on the first try. Quality data migration is not achieved on the first attempt. On the contrary, integration scenarios must be played out multiple times.

To do this, MeltOne recommends dedicating a test environment to run migrations as many times as necessary. This allows for detecting all errors upstream and resolving them as they arise. When data needs to be reprocessed, causing integration errors is a good sign. They help identify if any points need clarification, if certain business rules need to be re-explained or reviewed, and highlight significant differences that may exist between a Legacy system and the new solution.

MeltOne also recommends orchestrating “dry runs.” The objective is to perform a complete data takeover in a test environment. It is then important to follow the correct sequence to ensure overall consistency, much like a grand dress rehearsal before the final migration to the production environment.

4 – What Constitutes a Successful Migration?

Four key factors can be identified for a successful migration:

If you would like more information on this topic, particularly regarding managing a migration to an S/4 Hana environment, please do not hesitate to contact us: jsaccona@meltone.com. We will be happy to respond to you as soon as possible.