This is no longer a planning conversation
For years, CallidusCloud Commissions migration was treated as a future-state problem. "We'll assess when our contract is up." "It's on the roadmap." "We'll wait for the platform to mature." That window has closed.
SAP announced end of maintenance for CallidusCloud Commissions on December 31, 2026. After that date: no patches, no regulatory updates, no compliance fixes. Organisations still running Callidus after year-end are on unsupported software — and the migration partners with actual CallidusCloud internals knowledge are already being absorbed into projects.
The complexity of this migration is consistently higher than a standard ERP migration. Commission processing workloads — credit logic, quota attainments, payment history, earnings by plan component — are not what standard SAP migration accelerators were designed for. Most of them weren't.
The headline numbers
The data is from the broader SAP migration landscape — there is no published study specifically on CallidusCloud → SAP IM migration outcomes. The Horváth 2025 study surveyed 200 large-enterprise companies (€200M+ revenue) on SAP S/4HANA transformations broadly. ICM migrations carry additional complexity layers on top of the general SAP baseline.
The four gaps ICM migration plans consistently miss
General SAP migration playbooks and SI accelerators were built for ERP workloads — finance, HR, logistics. The CallidusCloud → SAP IM path sits at the intersection of several distinct complexity domains those frameworks either miss or treat as footnotes. Click each to expand.
CallidusCloud's Landing Pad was an intermediate data processing layer — built on Oracle Database with Informatica PowerCenter ETL on a Unix host — that customers used to preprocess and massage incoming data before it reached the Commissions engine. Many implementations had years of transformation logic, data cleansing rules, and feed standardisation built inside it.
There is no Landing Pad in SAP Incentive Management. The architecture doesn't support it. All Landing Pad processing must be rebuilt from scratch in a replacement integration tool: SAP Data Intelligence (SDI), Express Data Loader, SAP Business Data Cloud, or SAP Cloud Integration.
This is not a migration — it is a rebuild. The business logic embedded in Informatica mappings, Unix shell scripts, and Oracle stored procedures must be understood, documented, and re-implemented in a completely different toolchain. If your migration scope document doesn't have a dedicated Landing Pad workstream with its own timeline and resourcing, your scope is wrong.
Oracle PL/SQL and SAP HANA SQL Script are fundamentally different procedural languages. SAP provides the Advanced SQL Migration Tool (ASMT) specifically for this conversion. In practice, it handles the straightforward cases: standard DML, common function mappings, simple cursor logic.
What ASMT doesn't handle: CONNECT BY hierarchies, BULK COLLECT / FORALL, Oracle-specific date arithmetic, complex cursor logic, performance tuning patterns built for a row-store engine. SAP implementation partners typically cite 70–80% automation coverage from ASMT; the remaining 20–30% requires manual rewrite from first principles.
ICM environments frequently have extensive PL/SQL codebases — custom reporting procedures, data extraction scripts, validation logic, period-close automation. Teams that treat ASMT as "the migration tool" rather than "the first pass" will hit the 70% wall at exactly the wrong moment. Run ASMT early as a scoping tool — not during the migration itself.
Both CallidusCloud Commissions and SAP Incentive Management use the CS_ table prefix — which looks like continuity but isn't. Column names, data types, and relationships across many core tables changed between the Callidus Oracle schema and the SAP-native HANA schema.
Any custom SQL, any Crystal report that queries underlying tables directly, any data extraction or integration feed that references Callidus column names — all of it requires remapping. Standard SAP migration documentation rarely covers this at the table level. Teams that don't do a full CS_ dependency inventory before estimating scope will discover those dependencies when they break in production.
The action item: run a dependency analysis against every custom query, report, and integration feed. List every CS_ table reference. This inventory is the foundation of your actual migration scope. It consistently reveals 2–3× more downstream dependencies than informal estimates produce.
SAP's standard migration tools — LTMC, LTMOM — handle master and transactional data for core ERP objects. They were built for SAP ERP migrations, not for CallidusCloud Commissions. Commission data — pipeline results, credit assignments, quota attainments, earnings by plan component, historical payment records — is entirely out of scope for those tools.
This means every ICM migration team must build its own validation framework: queries that compare source data on Oracle against target data on HANA at a granularity that catches individual credit assignment errors, rounding differences at the earnings record level, and quota rollup discrepancies. This framework is a project within a project.
It gets scoped in the final weeks before go-live rather than at the start. That is the root cause of most ICM migration go-live crises. Build the validation criteria and the test queries in a sandbox, before the migration starts — not under time pressure at the end.
The four gaps above — Landing Pad rebuild, ASMT partial coverage, CS_ schema remapping, custom validation framework — are almost universally absent from general SAP migration accelerators. Discovering them late is expensive. Discovering them after go-live is catastrophic. Discovering them during budget sign-off is fixable.
Migration readiness checklist
Tick each item your team has completed. If more than two are blank, your scope is incomplete.
The resource window is narrowing
The constraint is not the technology — it is the people. Consultants who understand CallidusCloud internals and SAP Incentive Management configuration at the depth required to navigate the gaps above are a small community. Most are at major SIs. Most of those SIs have project benches committed through 2026 and into 2027.
Window to secure good ICM migration consultants is open but closing. Project start now means go-live before year-end is feasible for scoped, smaller environments.
Callidus + SAP IM dual-track specialists largely committed at major SIs. Independent consultants available at premium rates. Complex environments will not reach go-live before year-end.
CallidusCloud Commissions end of maintenance. No patches. No regulatory updates. No compliance fixes. Still running Callidus = operating on unsupported software.
Consultant rates projected +30–50% vs 2025. Demand for HANA specialists exceeds supply at most major SIs. Migrations still possible — at materially higher cost and risk.
The bottom line
The headline "60% of SAP migration projects overrun" comes from the broader SAP landscape. For ICM-specific migrations, the structural complexity is higher — not because the technology is worse, but because commission processing workloads don't fit cleanly into the standard SAP migration toolchain.
The teams that will come through this period with migrations on time and on budget are the ones doing the unglamorous upfront work: Landing Pad inventory, ASMT scoping, CS_ dependency mapping, validation framework design. None of that is heroics. All of it is boring. All of it prevents the 11pm go-live crisis where someone is hand-checking earnings records against a deadline.
The organisations still in "assessment mode" in late 2026 will be competing for the same constrained pool of consultants — at higher rates, under more pressure, with less room to recover when the scope surprises land.
Stay ahead of the migration deadline
Monthly updates on SAP Incentive Management releases, migration patterns, and practitioner notes — no noise.
📬 Get monthly updates