This is part of an ongoing blog series on SAP SuccessFactors HCM implementation. In this post, we explore how to define the data migration scope and the critical factors to consider when finalizing it. The information and approach shared in this blog are based solely on my experience working on SAP SuccessFactors HCM projects over the last 12 years. 

Data migration is one of the most complex workstreams in an SAP SuccessFactors Implementation project. It is often the primary factor that determines whether an implementation is a resounding success or a mess.

To define an accurate scope, we use at least four sections to conduct a “deep dive” into customer-specific information. Based on these findings, we can define the final project scope:

1. SF Module Scope: Which SAP SuccessFactors HCM modules are within the implementation scope?
2. Historical Data: How much data history needs to be migrated from legacy HR systems?
3. Countries in Scope: Which countries are included in this rollout?
4. Migration Requirements: What are the high-level requirements for data migration?

1) SF Modules in Scope:        

  Identifying which SAP SuccessFactors HCM modules are in scope is the first step, and it is relatively straightforward. However, identifying which data objects need to be migrated for each module is critical. Not every module will necessarily require data migration, but evaluating all requirements and documenting them for every module will provide a clear picture of the project scope. Ultimately, this is one of the key metrics used to define the total level of effort

2) Data Migration History  : 

Deciding on the volume of historical data to migrate into SAP SuccessFactors HCM is a high-stakes balancing act. While the “Top of Stack”  is a leading practice recommendation, sometimes customer-specific requirements often demand more history. Based on my experience, the following 5 items are critical to define the historical data scope.

Here is a breakdown of how those five requirements influence your data migration strategy; the list may vary.

• Historical and Legal Requirements: These are key driving factors in determining whether to migrate historical data. It is essential to document all country-specific requirements; based on these, a decision can be made regarding whether to migrate the data or maintain it within a legacy/archived system.

• Compensation Module: To run effective merit cycles or bonus calculations, we typically require up to one year of data. The specific duration will vary based on the “go-live” date.
• Rehire Requirements: Rehire policies often expand the scope to include the migration of terminated records. Depending on customer needs, you must identify how many years of terminated records are required for migration.
• Retroactive (Retro) Requirements: Determining how far back the system must go to run retro-calculations is critical. Furthermore, the volume of retro-transactions is a decisive factor in whether migrating historical data is necessary.
• Country-Specific Requirements: Local regulations significantly impact the decision to migrate history. It is mandatory to review all country-specific Reporting. legal and compliance requirements before finalizing the migration strategy.

 My Recommendation: I recommend doing  “Top of Stack” migration. If migrating historical data is absolutely necessary, it should be limited to a maximum of one year. Note that migrating history significantly increases project complexity. Specifically, the efforts required for data cleansing, validation, and loading will be substantially higher and must be factored into the effort, project timeline, and resource allocation.

3) Countries in scope and Source of data: 

Identifying all countries in scope is critical to the project’s success. As part of defining the geographic scope, identifying data sources is critical. If the HCM system is uniform across all countries, the impact on scope is minimal; however, a fragmented landscape of disparate systems will significantly increase project effort.

• Translation Requirements: The need for multi-language data mapping and system localization, which requires additional logic in data migration.

• Validation Complexity: Increased resource requirements for localized data cleansing and validation, which requires more effort.

 4) Different Types of Employee Data Populations and Scenarios: 

Identifying different employee population classifications and their specific scenarios is critical, as it requires a tailored data migration approach, design, and logic that directly impact the total migration effort.

Once the discovery scope is complete, we define the project scope in a detailed document. As the first outcome-based deliverable for the data migration workstream, this report clarifies our strategic choices—such as prioritizing ‘Top of Stack' data over full history. It also outlines unique customer requirements, etc. Based on this, we proposed a solution architecture for complex data migration requirements, tool selection for migration, cleansing, mock cycles planning, and a validation strategy.

Key Points to Remember:

• Clearly distinguish between “must-have” and “nice-to-have” requirements (e.g., full historical data vs. top-of-stack data) to manage scope and complexity effectively.
• Clearly document how to tackle customer-specific use cases when you migrate only the top of the stack. Eg: Retros, Historical Reporting, Rehire, Tenure etc. SI has to work with the customer to provide the right solution design based on customer-specific data (not a generic approach).
• The success of data migration heavily depends on the expertise of your System Integrator (SI) partner's key resources. It is critical to onboard key data migration resources with proven experience.
• Customer resource availability is essential at every stage. Assign dedicated team members who have a strong understanding of your data and business processes to actively support the project.
• Assemble a team focused on execution. Data migration requires significant hands-on effort, so prioritize contributors who deliver outcomes over those who only provide input.