Moving to a cloud-based HR solution like Employee Central has many aspects to consider. Right from getting the project management setup to the final go-live is a series of activities that needs expertise, coordination, and a well thought out execution plan. Each of these activities has their own significance and cannot be downplayed one over the other.
One such important activity is designing the data migration strategy considering various aspects specific to the customer legacy system and using Employee Central import tools to execute the transition to a cloud-based Employee Central HR system. In order to simplify this transition, SAP SuccessFactors product management has covered an exhaustive array of topics on designing the migration strategy covering technical and functional dimensions to consider in one of their latest
implementation design principle for SAP SuccessFactors (SFIDP) document.
This document was produced in close collaboration with SAP SuccessFactors partner Timonthy McApline from Rizing, and also had significant inputs from Anamarija Crncic-Samsa from Pentos, Prakash Swaminathan from E&Y and Gauthier De Smet from Comentec. Many thank to all these partners for collaborating with SAP SuccessFactors to come up with a great insight document on data migration to Employee Central.
I would like to share a highlight concerning the historical data topic from this document. One of the commonly asked questions is how much history should I bring from the legacy system to the cloud-based Employee Central system.
Importing historical data into Employee Central is an optional addition to the implementation project. You can decide to bring a bare minimum of a month's historical data or a year's record based on the needs of the customers. Bringing all the historical data from the legacy system not only amounts to complexity but is also an unnecessary & non-value adding task.
There are several advantages and disadvantages to including or excluding historical data. It is important to consider the scope and how much historical data will be included. The following are some of the advantages and disadvantages and what necessitates to consider historical data:
Advantages:
▪ Single Point of Entry: The data is in a single system and doesn’t need to be tracked down. The information is available based on permissions and can be accessed at any time without needing an external involvement.
▪ Trend Reporting: Reporting is available as a seamless option within the system without having to consolidate information externally.
▪ Retroactive Changes: Changes can be made before the go-live date and flow to the payroll as needed without having to access a third-party system.
Disadvantages:
▪ Mapping: The historical information will need to be mapped to structures and data points that might not be relevant to keep track of from a business standpoint, and thereby reduces the quality of data that is stored in the system. This increases based on how far back in time the data goes.
▪ Time and Resources: This will extend the project timeline to enable a greater resource inclusion for data migration.
▪ Limited to In-Scope: Information that is being captured for the scope of the project is what is included for historical data, any additional sources of information would need to be included as an independent source or custom object within the system.
▪ Organizational and Foundation Structure: Typically, with historical data, the further back the history is needed to be migrated, the more mapping and transformation is required. This can include greater provision for foundational information being imported into the new system. Most of which would be made inactive at go-live and exist purely for historical inclusion. The other consideration is the potential mapping of historical data points to current structures, this may not be completely feasible and would require either customization to include data from a historical perspective or the inclusion of “dummy” data on the current structure applying back to historical data. It also means that you have to enable more picklist entries to ensure the mapping of values between the legacy system and EC system matches.
Potential reasons why history would need to be included in Employee Central:
- Trend Reporting: The ability to be able to use the history of the entities within the Company is particularly useful when looking at reporting trends over time. This can be sourced within the Reporting module independently or pulled directly from Employee Central if historical records have been loaded.
- Compensation Merit Cycle: To perform a merit cycle within the Compensation module, a full year of data needs to be present that Compensation can use to complete the cycle. Compensation data can be a driving force for the inclusion of historical data. The current compensation merit cycle will need one year of history to perform a merit cycle successfully. This can be obtained either through historical inclusion of data as part of the data migration or creating manual imports into the Compensation module for the inclusion of the merit cycle for the first year of the system going live.If variable pay is inclued, then compensation history is mandatory.
- Legacy System Licensing: When moving from an existing legacy system into Employee Central there can be issues with access to the legacy system once Employee Central is live. Having these records available within Employee Central alleviates this concern.
- Country Specific Regulations: There are also legal/regulatory laws which may require several years of history to be accessible in the new system such as union regulations in the US.
- Variable Pay: If Variable Pay is included then at least a years Compensation history is required.
General History recommendation: There are customers who do not load any history at all but only the hiring record along with the latest record of the month of the go-live. With this kind of approach, the consideration is how the HR admin can manage the retroactive changes in payroll if there is a need. Therefore it is important to have the employee data of at least the number of months prior to go-live by which the employee /HR admins can still make changes and replicate back to the payroll system for retroactive calculations.
I hope this blog post was useful to know the different considerations while deciding on whether historical data is needed in Employee Central and if yes, how much is good. I invite you to visit the
document for a full-fledged discussion on the same topic and more.
I look forward to hearing about your experience and how you deal with this aspect of data migration design. Feel free to comment and ask questions.
