In 2018, SAP’s acquisition of Calliduscloud.com marked a pivotal moment in the evolution of their flagship Incentive Compensation Management product. Renamed as SAP Commissions, the product is undergoing a comprehensive architecture rewrite, transitioning to core SAP technologies and rebranded as SuccessFactors Incentive Management. This transformative change is a response to the ever-evolving landscape of technology and a strategic move to align with SAP’s broader ecosystem.

The crux of this transformation lies in the departure from the existing architecture, which is based on Oracle. This change is not merely a technological shift but a strategic necessity. The current Oracle-based architecture is set to lose support beyond 2026, prompting a critical decision for existing customers. They now find themselves at a crossroads, faced with the choice of either upgrading to the SAP HANA platform hosted on Google Hyperscalers or exploring alternatives within the Incentive Compensation Management (ICM) and Sales Performance Management (SPM) landscape.

Option #1 – migrate to SuccessFactors Incentive Management

This may look like the most obvious option, but to form the ROI perspective you need to consider a few facts:

• The migration will cost you. Yes, SAP will migrate the system “for free” for some selected customers, but even if you’re in that batch, the cost of license per payee is likely to increase. In other words, “free migration” means that you’ll need to pay for that later. Sorry, no lunch is ever free!
• If you’re not in the selected batch of customers, you’ll have to pay to migrate the system. Good news though is that all components can be migrated by specialized (and usually cheaper than SAP) system integrators. Even the Repository itself can be migrated using data and XML exports/imports, while other components (Landing Pad’s Informatica, Workflows, Reports etc.)) will need to be manually rewritten.
• One way to save a bit of budget on migration is to ask SAP to do a physical lift and shift of the repository (and it’s only SAP that can do it). Regrettably, all other components need to be manually rewritten, migrated.
• You may be asked to pay for two licenses for the period when the old system is in production and the new one is already provisioned. As soon as SAP makes the new system available (not when it’s fully migrated and operational!) the clock starts ticking. SAP may be persuaded to lift some part of the dual charge.

In other words, depending on your status with SAP you will face a distinct set of costs, but no matter what – there will be a cost.

Option #2 – migrate to another ICM system

The current situation, forced by SAP’s decision to discontinue support for the current SAP Commissions, creates a perfect opportunity to look around.

There are a few other vendors that offer similar class solutions – and a few contenders that more boldly go to the Enterprise space.

So, if you were to consider migration to another ICM system, purely from the budget perspective, here’s what you need to consider:

• “Migration” means actually “brand-new implementation”. The whole data integration, reports, outbounds and of course the compensation ruleset will need to be rewritten
• No automated migrations – that’s it. There may be some pieces that can be moved in a semi-automated manner (e.g. system history and prior results), but in general the migration will be a manual effort
• Dual license charges (for the old system and for the new one) are quite obvious, but these days platform vendors seem to be easily negotiated with.

Option #3 – a hybrid option

An option that is not immediately obvious it is a hybrid option – migrate the core repository to SuccessFactors Incentive Management, but all other components would go elsewhere.

This option is usually suitable only for companies that use the old SAP Commissions as a calculation engine and the data integration/reporting/dashboards/dispute resolutions are implemented somewhere else in the company’s enterprise infrastructure.

The migration in this case is straightforward – SAP migrates the repository (alternatively: the repository is migrated by XMLs by another system integrator, with some manual work involved).

Once the repository is migrated, the Outbounds need to be rewritten to produce correct output on HANA – and that’s it!

The CDL format of the new system is so similar to the ODI format of the old one that the Inbound data integration should work without major modifications.

A few practical hints from Sands Partners:

• Don’t shy away from calculating end-to-end ROI and considering multiple options. Moving to a new system, using a new system integrator or staying with SAP – all these options should be thoroughly investigated. Maybe an RFP is in order?
• Regardless of option chosen, do insist on a very detailed project plan. Plans built with only a few meaningless milestones like “workshops”, “design” or “migration” usually indicate that the plan is built with a limited understanding of the migration and is overly optimistic
• When migrating to a new platform vendor, dual charges (for the old system and for the new one) are not as obvious as it seems. Platform vendors seem to be quite flexible and understanding in this regard and can be negotiated to lift at least part of the initial charge
• When calculating ROI of the migration, do consider long term perspectives. Some companies are very creative to show that the migration won’t cost you anything in the first year, but then the real costs kick in