When a business acquires another organization, the need to migrate data from the acquired company’s ERP software introduces some unique challenges. This data must be aligned to the acquiring company’s corporate standard ERP.
In this blog, we cover how to manage an effective data migration from an acquired organization’s ERP software. While some of the specifics may vary, these best practices also apply to similar data migration scenarios, such as moving data when migrating from an old to a new ERP system.
Planning an Effective, Efficient ERP Data Migration Process
The goal of the migration process should be effectively integrating an acquired business’s systems into the target ERP environment. An acquiring organization must make sense of an array of various types of data within an acquired organization’s ERP system (and key integrated systems), including:
- Data-at-rest, residing in storage, including master data files and historical data on products, bills-of-material, routings, customers, vendors, closed sales orders, closed purchase orders, and more.
- Data-in-use that is currently being updated, processed, erased, accessed, or read by a system (such as in-progress sales orders) and must be captured as the system is migrated.
- Data-in-motion (sometimes called “data in transit” or “data in flight”) refers to data currently being transported between different locations (either within one system or between distinct systems). Purchases or sales orders that have been sent to a vendor but not yet processed are a prototypical example.
An effective migration strategy needs to identify valuable operational data across all of these data flows and repositories and adapt this data to the target ERP with minimal business disruption. Doing so successfully requires a carefully planned, multi-phase migration strategy.
Eight Key Phases for ERP Data Migrations
Below, we cover eight key steps for effectively onboarding a new organization’s data. Ultimately, the goal is to capture data that offers operational value without needlessly replicating reams of archival information in the target ERP system. Along the way, building an in-depth understanding of the underlying business is just as important as the technical challenges associated with the migration itself.
Phase One: Become Familiar with the Databases on Both Sides of the Acquisition
Building true familiarity with each organization’s database is an essential first step for planning an effective migration. This foundational knowledge should include insight into database structure and the availability of different tables, rows, and columns, and how this information is used in their applications. Typically, the IT team of the acquiring organization will be more familiar with their existing IT systems, and the crux of this effort is learning the details of the acquired company's databases and applications.
Phase Two: Understand Data Gaps
One ERP database may not record all of the same variables as another, which can lead to data gaps when two different systems are integrated. Data gaps are a natural part of any inter-organizational data migration, but it is important to identify these gaps proactively to develop a plan for addressing them. Doing so successfully requires a mix of technical savvy (ie. spotting the tables, rows, and columns that exist in one system but not the other) and operational knowledge to recognize the business impact of these gaps and plan accordingly.
Notably, a gap can include not only missing data but data that is recorded, calculated, or labeled differently in one business versus the other. Recognizing these issues requires genuine familiarity with the business applications, attention to detail, and a meticulous planning process.
Potential “gap-bridging” solutions include supplementing the database with external sources, identifying reasonable assumptions for estimating missing data, implementing new data entry processes, and recognizing data that is not required by the target ERP.
Phase Three: Identify Business Requirements for the Migration
In practice, this work occurs in parallel with the first two phases discussed above. As the migration team builds out its comprehensive survey of the respective databases, they should focus on documenting concrete business requirements for the target ERP system.
Identifying these requirements upfront is the best way to avoid extraneous migration work, ensure that critical data is captured, and focus the migration work on the data that matters most. In a legacy database that has been running for years, there may be thousands of tables, and not all will be actually valuable to the business. Identifying how much historical data will be migrated versus archived is also important. Migrating irrelevant data represents needless time and expense.
In an effective migration process, these first three planning-oriented phases will take much more time and effort than the following five execution phases. Getting to know an entire organization’s data structures requires time and collaboration! Doing so thoroughly is worth it to avoid business disruptions down the line.
Phase Four: Design Scripts for Replicating Data
Based on the initial planning work discussed above, scripts must be designed for replicating all relevant data, mapping it onto the standards of the new business, and employing the necessary assumptions to fill any data gaps.
Phase Five: Build the Requisite Scripts for Executing the Migration
With a detailed plan in place, the migration team can create the scripts used to execute the migration itself. There will usually be one or more scripts for each area of the business or business process.
Phase Six: Execute the Migration
Custom migration scripts are now ready to be run and begin replicating the acquired organization’s relevant data according to the data definitions of the target ERP system.
Phase Seven: Testing
A dedicated testing phase is critical for ensuring that these business-critical systems are ready to fulfill all relevant business requirements before switching over to the new environment. Scripts are evaluated through the creation of a test environment, which can be examined for completeness. Scripts are then adjusted, and the testing process is iterated until the database is correct. Typically, programmers focus on one operational area at a time, such as purchasing.
Phase Eight: Enter Production
If testing confirms that the scripts capture all the needed data to support the business’s operations, the scripts may be run to begin replicating the data to the production ERP database.
Need help with your IBM i data migration?
PSGi has experience supporting a number of complex ERP data migration projects, including working as a trusted support provider for manufacturing organizations that have become adept at managing multiple manufacturing acquisitions annually.
These projects have repeatedly demonstrated that a detail-oriented approach, backed by pre-prepared templates for gathering knowledge on an organization’s data gaps, is the best way to streamline the migration process.
