ERP War Stories: When Should Data Migration Begin?

Over the past 20+ years of managing ERP implementations, one topic that often creates uncertainty on projects is when data migration activities should begin and how it should progress throughout the implementation lifecycle.

Organizations often assume that data migration is a task that happens close to go-live. In reality, successful ERP implementations treat data migration as an iterative process and begins early; because company data is required during various aspects of build testing which occurs prior to User Acceptance Testing (UAT).

Situation:
We always recommend treating data migration as a phased activity that occurs during the design phase and is aligned with the key implementation milestones as shown below:

• ~20% (Process Walkthrough / Design Validation): Initial data structures and mappings are reviewed to ensure the system can support the required business data.
• ~50% (Build & Early Testing): First-pass data loads occur to validate configurations and begin identifying data cleansing needs.
• ~80% (Conference Room Pilot / Integrated Testing): A more complete dataset is loaded to simulate real business scenarios and validate reporting and operational processes.
• ~100% (Go-Live): Final cleansed and validated data is migrated into the production system.

However, in one of our ERP implementations, the client’s data migration resource became unavailable, which delayed the data migration effort. As a result, the project team was forced to conduct build testing using mock data, making the testing process both inefficient and less meaningful. The lack of real data slowed down testing cycles and reduced overall confidence in the system’s outputs.

In addition, because data migration activities started later than planned, it took longer to identify and resolve data quality issues, incomplete mappings, and structural inconsistencies.

Notable Risks:
Data migration requires thorough planning. Without it, organizations often encounter issues during system testing, including poor test relevance, data integrity concerns, incomplete test scenarios, reporting inaccuracies, and delays to the overall go-live timeline.

Mitigation Consideration:
To address these risks, we recommended to the client to increase their data migration resources to accelerate the process and stabilize timelines. We also augmented the client’s team to ensure the migration effort was properly supported without impacting the broader project plan. Our approach focused on prioritizing critical data first, ensuring relevant client data was available for the second half of build testing. From there, we accelerated the full data migration effort so that all required data was in place ahead of subsequent testing cycles. This Mitigation recommendation brought the schedule back on track.

Lessons Learned:
Data migration should begin early and continue throughout the implementation lifecycle. Organizations that adopt this approach build greater confidence in their test environment, as more data is available to support thorough testing. This allows a wide range of scenarios, both simple and complex to be validated, while significantly reducing risk leading up to go-live.