Expand +



How to Optimize Your Migration to SAP SuccessFactors Employee Central: Live Q&A with Ari Levin

January 25, 2017

Conversion and migration to SuccessFactors Employee Central can be a complex and costly activity. In this session, HR 2017 speaker Ari Levin shared insights in the migration to SAP SuccessFactors Employee Central. Learn what factors your organization needs to consider when moving from your on-premise SAP ERP HCM to SAP SuccessFactors Employee Central.

Live Blog How to optimize SAP SuccessFactors Employee Central

Ari Levin: Hi Folks. I work for Accenture Software for HCM as a Solutions Architect in the SAP HR/SAP SuccessFactors space. I've been in the SAP SuccessFactors space since the acquisition, and I'd say that my primary focus areas within the SAP SuccessFactors space are probably migration, testing, and security, as well as development of extensions and commercial software through the SAP HANA Cloud Platform. I've also got a lot of experience with some more technical areas such as SAP SuccessFactors APIs so if you'd like to delve in there, let me know. I’m happy to be here and I'll answer your questions to the best of my abilities. Feel free to follow up with me afterwards at

Comment From Mr. Maateeq: What are the security precautions you take to ensure confidentiality of employees’ data in the cloud?

Ari Levin: Security usually comes down to two factors when we deal with a project environment (in this case, for migration): authorization and data scrambling/masking. There’s a fine balance between the access you'll give out versus the amount of scrambling or data masking that you can execute in your system of interest. In a productive environment, you'll be much heavier with security with all real data, whereas in a QA environment, or post mock, you'll want to ensure you have data secured to a reasonable level both through security roles as well as scrambled data. Data scrambling can be challenging in SAP SuccessFactors solutions, but there are a few tools you can look at to make this easier, which I'm happy to elaborate on if you follow up with me afterwards. I'll also throw out a few ideas here on actual conversion practices: for example, the less data you actually extract from the system to a secondary server or a desktop, the better you'll be. This means that you can look at taking advantage of web services to do a direct data load for your migration rather than using flat files that are extracted, massaged, and so on. 

Comment From Ramachandra: What are the new business rules written in SAP SuccessFactors Employee Central? Please give some examples.

Ari Levin: The rules engine has been built out quite a bit since it was first introduced. Remember that it’s very beneficial for front end validation, but it won't cover interfaces or activities where the end user who is inputting the data won't know the valid responses. Here are some examples of rules you could write.

  1. Issue a warning for date of birth field if employee is below 18 years old. (This rule helps in validating the employee's age. The system will show the message if the employee's age is less than 18 years.)
  2. 30 days before contract end date is reached, a reminder will be sent. The reminder will appear in the “to-do” of HR manager.
  3. 30 Days before probationary period end date is reached, a reminder will be sent. The reminder will appear in the “to-do” of HR manager.

Comment From Jens: The sequence of migrating data to EC is first the foundation objects and then the employee data. In the foundation object department, there is a field “HeadofUnit” which refers to a user. How do we populate this field with a value in EC? If it is populated during migration of departments, it will fail during import to EC as it refers to a non-existing user since the employee data has not been migrated to EC yet.

Ari Levin: Department needs to be loaded twice. First without HeadofUnit as you mentioned because the user data won't yet be in the system. It then needs to be reloaded after the user data makes it into the system.

Comment From Marie: We will be implementing EC next year. How can we use global assignments functionality in EC in order for us to keep the history against a single employee ID for modules such as Learning, Succession, and so on without enabling something like concurrent employment in SAP where we have payroll on premise? Our typical process at the moment is to create a new employee ID in payroll and the talent modules are manually updated with history where possible.

Ari Levin: When using the Global Assignment functionality, the employee retains their global ID and the history associated with their movement around the organization. Within SAP SuccessFactors, the “home” ID, 1234, is replicated to the current “host” assignment ID to become 1234-1. If the employee has a second assignment, it is tracked as 1234-2. All are circled back to the same unique employee ID. For integration with LMS, the current standard takes both the home and host records and replicates this into two records into different profiles within LMS in the standard connector. There are options using a custom connector to consolidate into a single LMS record, although this deviates from the standard and the connector would not be supported by SAP like they do the standard connector.

Comment From Keith Odom: I am very interested in tools and processes related to SAP SuccessFactors migration. What are some of the best tools to structure the data (such as the import template files in EC) before the import attempt? Are there any defined processes for data validation post-import other than using reporting to extract and test?

Ari Levin: So there are a number of standard SAP tools out there for migration, as well as a number of vendor tools also in the space. I can give you a brief outline of the SAP tools and feel free to follow up with me to discuss other vendor tools if you'd like (for example DCM which Accenture offers). SAP actually has a number of tools with the aim of moving you to SAP SuccessFactors from SAP HCM. Two that pop out are Infoporter (which was recently rebranded from SAP Migration Tool), as well as BusinessObjects Data Services. Each has their own strengths and weaknesses which is a large conversation in and of itself but in in general, the first is an ABAP tool while the second is a standalone Java tool. Both have templates and some process models. I really suggest you contact me as I've got a lot of information in the space which might be worthwhile. I also stress that I know from experience that its extremely important to research, plan, and use a tool for migration because it will save a tremendous amount of time and effort in conversion. Last comment here: there are a few options of actual loading. Flat files have been traditional but now you can take advantage of web services to load directly as an alternate option. Feel free to ask follow ups here for clarification.

Comment From Mohammad Faisal: What is the difference between ODATA API and SFAPI data?

Ari Levin: So ODATA and SFAPI are the two most common APIs in use right now. Just as a primer, an API is how an external extension would either read or write data to SAP SuccessFactors as we don't have direct database access like we did in SAP HCM. SFAPI is the SOAP-based, older of the two APIs and is still supported but not developed going forward. ODATA is really the gold standard now in terms of supported and developed APIs for SAP SuccessFactors, so I strongly suggest researching ODATA if you're looking at using the APIs. The biggest drawback in my mind to APIs in general are that they are not yet covering 100% read and write of all fields in all modules. EC is pretty well covered, but as soon as we leave EC things get a little sparser. Make sure you've done your research to know which fields you're trying to access and if they are properly supported.

Comment From Barinder: Do we bring employee and position master data from SAP ERP Central Component to EC via a load or re-entry in the new system? What if the data fields do not match one to one?

Ari Levin: I'll try to give a blanket answer here, but in general your conversion is going to involve taking both foundation objects (what you might traditionally think of as PD objects) as well as user data from the PA system. What you'll very likely need to do is perform an initial load into SAP SuccessFactors as a one-time conversion before you turn on any interfaces for data to flow back and forth from the two systems in such a model. It’s very important to be able to do a reconciliation on the data in both systems as I cannot stress enough that you will likely run into issues with specific employees, fields, records, and so on in conversion and you need to ensure you go live with as clean data as possible. There are some tools in this space — if you follow up with me, I can point them out to you. Now the challenge, as you noted, is what do we do if the fields do not match one to one? In this case, you really need to have logic built into either middleware or your conversion tools to be able to handle this. I'll elaborate a little more in the next question on splits.

Comment From Jens: One of the requirements when preparing the SAP ERP HCM system for data migration is to split all PA infotypes on the cutover date (as described on page 12 in the SAP Integration Guide “Migrating Data from SAP ERP HCM to Employee Central” – version Q4-2016). What about the PD infotypes (1000, 1001, 1002, and so on) containing the organizational units and the positions – should they also be split?

Ari Levin: So typically we would not suggest bringing over historical records by splitting PD data for foundation objects. This can be done if you really want the history in the system but usually it will be somewhat limited and could take a lot longer to perform the actual conversions. In general, date splits are very tricky to handle. If you think about a load like user into EC, this file takes data from many different sources — for example infotypes 0000, 0001, 0002, and so on. Those infotypes will almost never line up properly from a dates perspective and need to be collapsed into a single record or multiple records based off of a split. It will make your life easier if you're only converting current data, but this won't always be possible. There's no easy answer and you just have to make sure you're properly prepared for this and plan it out in detail with your conversion team, and then have a way to accurately reconcile this post conversion.

Comment From Barinder: Is workflow based on org structure or job families or identified approvers? We don't have a job family concept in ECC; how does this work in EC?

Ari Levin: There are many different workflows within EC, and in general you have quite a lot of leeway in terms of how they are configured. There's no one answer here but they can be configured to be triggered or flow to a specific user, a group of users, managers, and so on. It’s really a question of how you want to configure for the specific workflow. If you had a specific vanilla workflow in mind, let me know and I'll try to elaborate.

Comment From Deepak: We have multiple SAP and non-SAP back-end systems that we have to keep in sync once we decide to implement EC. Which middleware (HCP/HCI) do you recommend to enrich/customize the message flowing between SAP SuccessFactors and all the other systems? What is your experience with standard web services integration with SAP systems?

Ari Levin: Ok so there are two main middleware offerings out there as you probably know... HCI (SAP HANA Cloud Integration) as well as Dell's Boomi offering. I would say that Boomi has been around a lot longer and is likely more proven, while my sense is that HCI is definitely the path that SAP SuccessFactors is trying to travel down as part of an Integration-as-a-service offering. Each has their own strengths but I can tell you that HCI is much newer and hence not as in use as Boomi would be, but probably where more development is being sunk in now. For custom integration via web services, as I mentioned in the API question, you'll be more limited outside of EC, but it’s definitely worthwhile exploring as there’s a ton of work going on in this space and it’s a huge development area. I work on a regular basis with HCP and we've found it to be a very stable, well documented, and responsive platform. Happy to elaborate further with follow-ups. This is quite a large topic.

Comment From Mohammad Faisal: Is it possible migrate/interact business rules from SAP BRFplus (rule engine) tool to SAP SuccessFactors?

Ari Levin: I'm not so familiar with the SAP on-premise BRF tool, but if I had to guess I would say no. Rules engine is pretty SAP SuccessFactors specific. I will do a little looking into this for a follow-up.

Comment From Barinder: Which mandatory fields from HCM PA and OM are required for migration to EC?

Ari Levin: Unfortunately, there’s no easy answer here. This will depend entirely on your configuration, modules used, conversion strategy, and so on, but you're looking at potentially hundreds of fields here. You can start to look at the required fields by looking at the conversion templates supplied by SAP SuccessFactors load programs. This is a start, but it can be very tricky to map from HCM to SAP Successfactors, so you'll want to ensure you work with someone who has experience here and is using the appropriate tools and templates that are available in the space.

Comment From Chetan: If there are active workflows in the legacy system and this workflow data needs to be migrated, can we really do this workflow migration in the new system or take cutover and complete those pending workflows in legacy?

Ari Levin: I'm not familiar with a way to convert workflow in process. I think the typical process involves creating a blackout date where you'd start either a paper process or actually transacting in the new system. It could be tricky depending on how many in-progress workflows you have, but I don’t think there are other options.

Comment From Venkat: Can we allow employees to change their W4s and bank info on EC and transfer that info to on-premise payroll?

Ari Levin: In general, you can use EC as an ESS tool to allow employees a front end for data entry and then have that data flow back to ECC or EC Payroll. Just make sure you have an appropriate strategy for moving that data in an interface.

Comment From Lili Shippe: How do you make sure data migrated to EC will be in a shape that downstream talent modules will have all user data they need?

Ari Levin: With lots and lots of good planning and testing! Again, unfortunately there's no one size fits all answer here as it will depend on module and functionality used. My recommendations in general are to make sure you've thought through and mapped out your conversion, performed several mocks and used the mock data for testing, and then reconcile appropriately post conversion to ensure data accuracy.

Comment From Mohammad Faisal: What tool would you recommend to migrate configuration from one instance to another? For example, from dev instance to test and from test to production?

Ari Levin: So we can split this into two different answers. SAP SuccessFactors has a tool that’s in use, but certainly still being developed, called Instance Sync. Instance Sync is meant for this specific purpose which is to transfer configuration from one system to another. If you are planning on using this functionality, I encourage you to read up and research as well as test thoroughly because I know there's a lot of work yet to be done on the tool. They've also just recently opened up Instance Sync to ODATA which is encouraging. There's also the other side of the coin which is transferring employee data or scrambling it from one environment in SAP SuccessFactors to another. There's no standard tool right now that will do this but Accenture has a tool (Clone and Test) which covers the functionality. I don't believe there are other tools in the space, but please don’t quote me!

Comment From Lili Shippe: Did SAP create the "custom connector to consolidate into a single LMS record" that you mentioned? Did your client use it on a regular basis? I have a client with a similar situation and they want to know if they can avoid manual merge of many user accounts daily.

Ari Levin: Unfortunately LMS is not an area I have much expertise in. If you follow up with me afterwards, I'm happy to put you in touch with an expert who can answer appropriately.

Comment From MBurns: What have you seen to be the top 2-3 challenges organizations have faced moving from on-premise to SAP SuccessFactors?

Ari Levin: Plenty to say here so I'll just choose a few that pop out and I'll focus on aspects of the actual conversion/migration. Remember my slant is on the actual process of conversion and less on the strategic configuration decisions for the system that will be converted to.

  1. Data cleansing is often overlooked and causes huge impacts to the success of a system. I suggest putting an emphasis here if you've been transacting in a legacy system for any real amount of time.
  2. Reconciliation to validate a successful migration can be difficult because of access to data in SAP SuccessFactors as well complex mapping for conversion. Make sure to think through an appropriate strategy for post migration.

Comment From Guest: Are there separate SAP SuccessFactors roles or do those reside in native SAP?

Ari Levin: SAP SuccessFactors has its own security parameters and what you might consider roles that are specific to its modules (EC, Talent, Onboarding, and so on). They've come a long way since the company was acquired and are pretty flexible now. You won't see the exact same setup though as you'd be familiar with in SAP.

Comment From Mr. Maateeq: How long does it take to move to SAP SuccessFactors and how much does it cost?

Ari Levin: Unfortunately, this is really impossible to answer. It depends on a number of different factors including modules in scope, legacy system, conversion strategy, number of employees, and so on. It’s best to have a conversation with SAP SuccessFactors or your integration partner for more information and a business case.

Comment From Mr. Maateeq: What will happen if we never move to SAP SuccessFactors and contine using on-premise HCM?

Ari Levin: There's an end date to support of SAP on-premise HCM. I believe the last I heard was 2025 but this date has moved at least once that I can remember. I think what’s important here is to understand that SAP on-premise isn't going away anytime soon, so there's no need to panic and make decisions today. That being said, the cloud is definitely where SAP is spending the bulk of their investment for HR and technology in general (see SAP S/4HANA, Hybris, Ariba, Concur, and so on). It definitely makes sense to look at a roadmap for how you might move to forward technologies so you have a plan in mind.

Comment From Mr. Maateeq: How frequently are changes applied and how can custom enhancements be accommodated?

Ari Levin: Enhancements can really refer to a few different technologies used within SAP SuccessFactors — things like custom objects through MDF (Metadata Framework) or perhaps custom development extensions through HCP. I can expand on that if need be. Changes are applied to SAP SuccessFactors through quarterly releases. I haven't heard of any major issues that I can think of around MDF objects through a release. We do occasionally run into changes around APIs for HCP extensions which need to be dealt with accordingly, but it’s usually something small around the update and SAP SuccessFactors is quite receptive to fixing ASAP.

Comment From Chetan: Are there any integrations or options/ templates to convert or map SAP-based roles into SAP SuccessFactors RBP?

Ari Levin: Good question. I remember looking into this a while ago and I think at the time there were not any easy ways to load up RBP outside of a flat file (for example, through ODATA). This might have changed and actually as you ask the question, I find myself curious so I'll look it up. I know there are certainly templates that can be used and I don't remember this being a particularly difficult exercise the last time I did it so that's definitely an option for you.

Comment From Terrie: How are interfaces to/from EC typically handled — so data received from or sent to other systems? For example, is a separate programming language used versus query tools or other tools/methods?

Ari Levin: Depends on the setup, but I'd say that a hybrid or side-by-side setup typically involves the use of some middleware to build out conversion rules and other considerations when transferring back and forth from SAP SuccessFactors and ECC. If you think of PI/XI in ECC, Boomi or HCI would be comparable from a technology perspective. On either end you could use different languages to execute the command but likely on the SAP side you'd utilize ABAP for the data transformation and pulls, while on the SAP SuccessFactors side you'd use something like a Java or Javascript to access the data.

Comment From Mohammad Faisal: How do you handle quarterly releases that occur during SAP SuccessFactors implementation?

Ari Levin: SAP SuccessFactors is usually pretty good about letting out what they plan in the coming releases. You'd usually have experts either internally or from your SI who are involved in this and would analyze appropriately. A good example here would be when an object is rebuilt in SAP SuccessFactors using MDF (cost center was an instance of this) where you could choose to use the old cost center or load the new MDF object when it was released. There’s no one-size-fits-all solution, but I would wholeheartedly recommend specifying someone on the project to do an analysis. If you're using one of the bigger SIs, this usually would be part of the standard process.

Comment From Raj: We are migrating into EC and need to have our on-premise SAP still intact. For integrating our data from EC to ERP HCM system, do we need to create any new configuration that was created in EC again in the ERP system? For example, New Work Schedule Rule is created in EC — can we just send that data back into the ERP system such that it will update configuration tables or do we need to create this manually again in ERP system?

Ari Levin: Usually your middleware would handle this. You could do something like build a conversion table within your middleware. There definitely could be adjustments to either side’s configuration depending on the specific example.

Comment From Chetan: What if I want to migrate data from production to quality? What steps should be considered? An important aspect to add here is masking of certain fields. How can we mask certain salary and sensitive fields while moving data to QA instance, which can be later used for testing?

Ari Levin: So I know of two ways to handle this. The first is to do a manual load using a marked up flat file after a mock is done to manually mask the field. The only other way I know of to do this is to use an HCP application. Clone and Test, for example, does data scrambling. Follow up with me on that if you'd like more information.

SAPinsiderMatt: Thank you, Ari, for all of your insightful answers and thank you to everyone who participated in the today’s chat. You can review the Q&A chat replay at any time, and I will alert you by email when the transcript of today’s discussion is posted. 

Ari Levin: Thanks so much for all of your great questions. I will follow up where I haven't yet responded but again, feel free to reach out to me and if I haven't answered your question fully or if I can't answer it, I'll direct you to another expert:

An email has been sent to:

More from SAPinsider