Human Capital Management Blogs by SAP
Get insider info on SAP SuccessFactors HCM suite for core HR and payroll, time and attendance, talent management, employee experience management, and more in this SAP blog.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Special considerations to migrate legacy SAP SuccessFactors integration content to SAP Cloud Platform Integrations

gerald_reinhard
Product and Topic Expert
Product and Topic Expert
‎2020 Feb 11 11:48 AM
2,378

Introduction


Implementation design principles (IDPs) for SAP SuccessFactors solutions complement existing implementation handbooks by addressing real-life implementation challenges as well as frequently asked questions. They are best practices "verified" by product in collaboration with our partners. In this blog post I like to share some highlights from the updates we did to one of those IDPs. In our initial IDP we explained best practices to migrate integration content for SAP productized integrations to SAP Cloud Platform Integrations (CPI). Gurpreet wrote about this document also in his blog post.

In the updated version of the document I added findings from customer and partner conversations. Those include

  • best practices and know pitfalls in case of a phased migrations,

  • insights into what partners, such as ADP, are doing with their payroll integrations,

  • dependencies between the migration of the integration content and future plans of a customer to move to SAP S/4HANA,

  • indicators of a low risk migration project and

  • benefits of the migration to SAP Cloud Platform Integrations.


Problem Statement


In this blog I would like to focus on a challenge associated with a phased migration. In general, phased migrations are used to mitigate risk. In the case of a migration from a legacy middleware and middleware content to the latest content on SAP Cloud Platfrom Integrations, we observed projects attempting to do a phased migration also for a single integration content based on a country approach. This means we keep for some countries the integration on the legacy middleware and middleware content while some countries will be migrated to the newest content version running on CPI.

The problem associated with this approach is that some integrations are using a unqiue setting in one of the connected systems which does not allow to configure two different middleware. As a result splitting up an integration on a country basis is only possible if those two countries are managed in two different systems or tenants.

The picture below illustrates this based on the integration from SAP SucessFactors Employee Central (EC) to a SAP Payroll(PAY). Details of this integration can be found here.

This integration uses a setting in the payroll system (PAY) in transaction SOAMANAGER which defines the endpoint of the to be called middleware. This setting is used to trigger the integration but also to send back confirmation messages. Coming back to the example of migrating this integration on a country basis, this is technically possible in this setup as long as both countries are separated in the two payroll tenants or two payroll systems. I write "technical possible" here because this mixed scenario is not a scenario we recommend, since we do not have any validation results from customer and partners or internal test.

The important point I like to make here is that this scenario is technically not possible in case both countries are in the same payroll tenant. In the second row in the picture below this would exactly result in a setup where the unique setting in the SOAMANAGER can either point to new or the legacy middleware and its content but not to both.



The problem described above is also true for custom integrations or other SAP packaged integrations which are making use of a similar concept calling a listener in the middleware. This is an important constrain to be considered, when doing a phased approach.

Other constrains to be considered are dependencies between integrations, for example the employee time replication and the employee data and organizational assignment replication.

Solution Proposal


In general we do not recommend to do a phased migration within a single integration based on filter conditions such as country. If this can not be avoided, someone has to look out for dependencies like the one mentioned above to avoid facing bigger challenges. So what is a good approach for a phased migration?

Customer usually have multiple different integrations types running which also do not depend on each other, example of those different types include:

  • Different Endpoints, e.g. integrations between EC and 3rd Party and LMS and 3rd Party

  • Different Integration providers, Custom Integrations, 3rd Party Integrations, SAP Packaged Integrations

  • Different Data, e.g. Cost Center replication and Employee Replication


It is more secure to migrate those independent integrations in a phased approach rather than migrating a single integration on a country basis. Especially in case of a employee replication where people can also move from one country to another, there might be additional issues in case the data being created between legacy and newest integration differs. In a worst case the legacy integration is not aware of the data format of the new one and might face issues in this case.

Hence a good approach to migrate in a phased manner is for example to pick some of the custom integrations first and migrate SAP Packaged Integrations later (or the other way around). Additional risk can be mitigated if data being transferred and systems involved are different for the two. Also within SAPs packaged integration portfolio there are candidates to migrate independently from each other, e.g. the Cost Center packaged Integration and the Employee Data and Organizational Assignments packaged integration.

Outlook


Beside sharing those thoughts, this is also a call for action to share your best practices with respect to managing such a migration projects:

  • Did you make use of legacy interfaces to test the correctness and completeness of the new migrated interfaces on SAP Cloud Platform or did you rely on your existing test case only?

  • Did you implement a fall back scenario on the legacy integration to go back in case of issues?

  • Did you use the chance to refactor your legacy integrations before migrating them?

  • What are your best practices for a phased approach of integrations to SAP CPI?


 

Related Material



 

 
Popular Blog Posts