- ▸ SAP ECC standard support ends December 2027, with extended maintenance available to 2030 at a premium. Migration is happening now, not in future planning cycles.
- ▸ 30% of SAP migration projects in 2026 are over time or over budget. Only 8% finished on schedule per the Horváth 2025 study.
- ▸ PL/SQL reporting procedures do not translate to HANA SQL — they require full rewrites, not conversions.
- ▸ Callidus Commissions schema (CS_ tables) to SAP Commissions schema (CSC_ tables): table names change entirely, not just the database engine. Most migration guides don't cover this.
- ▸ Start resourcing now. The consultants who know both Callidus and SAP SuccessFactors IM are already booked through 2027 at most SIs.
Migration is live — not planned
For the better part of a decade, SAP ECC migration was a conversation that happened in future tense. "We'll migrate when the platform matures." "We'll assess S/4HANA when our contract comes up for renewal." "It's on the roadmap for next year." Those conversations are over.
As of early 2026, legacy ECC usage has dropped below 50% globally for the first time since S/4HANA launched. SAP's own metrics show more than half of its enterprise customer base is either actively migrating, on S/4HANA in production, or in formal project initiation. The tipping point was December 2027 — the end of standard SAP ECC support. Extended maintenance is available until 2030, but at a significant premium and with no new functionality. The business case for staying on ECC beyond 2027 is deteriorating quarter by quarter.
What this means in practice: every major SI has migration projects running in parallel. HANA infrastructure specialists are in short supply. Migration consultants who know legacy ECC internals and S/4HANA configuration are a constrained resource. And for ICM teams specifically, the complexity of migrating commission processing logic, historical data, and reporting infrastructure is substantially higher than a standard ERP migration — because most standard migration tools and most migration consultants were not built for commission processing workloads.
The headline numbers
The market data from 2025 and early 2026 is sobering for anyone who thinks SAP migrations are routine infrastructure projects:
Only 8% of SAP migration projects finished on schedule. That is not a rounding error — it reflects a systemic underestimation of migration complexity across the industry. The Horváth study looked at large enterprise SAP migrations broadly. For ICM-specific migrations, which involve additional complexity layers that most SAP migration tools and methodologies simply do not address, the on-schedule completion rate is likely lower still.
The consulting rate projections are also material for budget planning. HANA specialists who understand both the database architecture and commission processing logic are among the most constrained resources in the SAP partner ecosystem. Organisations that have not started resourcing their migrations will be competing for a smaller pool of available consultants at higher rates in 2027 and beyond.
What most migration plans miss for ICM
Standard SAP migration tooling — SAP's own RISE methodology, typical SI accelerators, and most migration assessment frameworks — was designed for general ERP workloads. Finance, procurement, logistics, HR. Commission processing sits at the intersection of several distinct complexity domains that most migration frameworks treat as afterthoughts, if they address them at all.
There are three gaps that consistently appear in ICM migration plans that have not been built by people with deep commission processing experience:
Oracle PL/SQL and SAP HANA SQL are not compatible. There is no automated conversion tool that will take a PL/SQL stored procedure and produce a working HANA SQL Script equivalent. They are fundamentally different procedural languages with different syntax, different control flow, and different performance characteristics.
ICM environments built on Oracle frequently have extensive PL/SQL codebases — custom reporting procedures, data extraction scripts, validation logic, period-close automation. Every one of these requires a manual rewrite. Not a line-by-line translation, but a rebuild from first principles using HANA SQL Script and an understanding of how HANA's column-store engine processes data differently from Oracle's row-based architecture.
When migrating from Callidus Commissions to SAP SuccessFactors Incentive Management, the underlying database schema changes entirely. Callidus Commissions used a schema with table names prefixed CS_. SAP Commissions and SAP SuccessFactors IM use a schema prefixed CSC_.
This is not a rename. The structure, relationships, and data types across many tables changed between the Callidus and SAP-native schemas. Any custom SQL, any reporting that queries underlying tables directly, any data extraction or integration that references Callidus table names — all of it requires updating. Standard SAP migration documentation rarely covers this at the table level. If your migration plan does not include a mapping exercise that identifies every downstream dependency on CS_ tables, you will discover those dependencies when they break in production.
There is no standard SAP tool that validates commission data integrity across a migration. The standard SAP migration tools (LTMC, LTMOM) handle master data and transactional data for core ERP objects. Commission data — pipeline results, credit rules, quota attainments, payment history, earnings by plan component — is out of scope for standard migration tooling.
This means every ICM migration team needs to build a validation framework that can compare source data on Oracle against target data on HANA at a level of granularity that would catch individual credit assignment errors, rounding differences at the earnings record level, and quota rollup discrepancies. Building this framework is typically a project within a project — and it is consistently underestimated in scope because it gets scoped in the final weeks before go-live rather than at the start of the migration.
If your migration methodology came from an SI's standard SAP S/4HANA playbook, check whether it covers commission processing specifically. The gaps above — PL/SQL to HANA SQL rewrite, CS_ to CSC_ schema mapping, data validation framework — are almost universally absent from general SAP migration accelerators. Discovering them late is expensive. Discovering them after go-live is catastrophic.
The specific ICM migration challenges
Beyond the three structural gaps, there are four areas where ICM migrations consistently encounter problems that require specialised knowledge to navigate:
Credit rule logic differences. The credit rule engine in Callidus Commissions and the credit rule engine in SAP SuccessFactors IM handle split-territory credits, overlay credits, and draw-on-commissions differently. Rules that produced correct output in Callidus may produce subtly different results in SAP SuccessFactors IM even when they appear structurally identical. Testing credit rule output at scale — across tens of thousands of transactions — requires a structured comparison framework, not a spot-check approach.
Groovy versus legacy Callidus workflow. SAP Advanced Workflow uses Groovy scripting. Legacy Callidus workflow automation used a proprietary scripting model. Migrating workflow customisations is not a syntax conversion — it requires understanding what each legacy workflow was doing and rebuilding that logic in Groovy with an understanding of SAP Advanced Workflow's execution model. Teams that are Oracle/PL/SQL-heavy and have not built Groovy fluency yet will feel this gap acutely.
Historical data migration for reporting. Compensation history — what a sales rep earned, in which period, against which plan, with what credit assignments — is often required for regulatory reporting, dispute resolution, and sales rep visibility going back three to five years. Migrating historical earnings data to HANA in a format that both the new SAP schema and any downstream reporting can query correctly requires careful data modelling. This is frequently descoped from migration projects to manage timeline, and then added back as a post-go-live workstream when sales reps can't see their own earnings history.
Compensation statement redesign. If your compensation statements are built on Crystal Reports against an Oracle database with Callidus schema, the migration affects both layers simultaneously. The Crystal report templates reference CS_ tables. The underlying database is changing to HANA with CSC_ schema. Both the query layer and potentially the reporting engine need to change at the same time. This is one of the most common sources of period-close emergencies in ICM migration go-lives.
Timeline reality: the resource constraint is already here
The most underappreciated risk in ICM migration planning is not technical — it is human. The consultants who understand both Callidus Commissions (the legacy platform) and SAP SuccessFactors Incentive Management (the target platform) at the depth required to navigate the challenges above are a small community. Most of them are at major SIs. Most of those SIs have their project benches committed through 2026 and into 2027.
The organisations that will complete their ICM migrations on time and on budget are the ones that started resourcing decisions in 2025 and early 2026 — not those who are still in assessment mode in late 2026 trying to build a team from scratch.
What you can do now
Regardless of where your organisation is in the migration planning cycle, there are concrete actions that move the needle and reduce late-stage risk:
Run a dependency analysis on every custom SQL query, every Crystal report, every integration feed, and every PL/SQL procedure in your commission environment. List every CS_ table reference. This inventory is the foundation of your migration scope — and without it, your project plan is built on assumptions rather than facts. This exercise typically reveals two to three times more downstream dependencies than teams estimate informally.
There is no shortcut here. Take your PL/SQL procedure inventory and for each one, document what it does in functional terms — not what the code says, but what business outcome it produces. That functional description becomes the specification for the HANA SQL Script rewrite. Doing this in advance of the migration project proper means you arrive at the migration with specs, not just legacy code. It also surfaces the procedures that will require significant redesign versus those that are straightforward rewrites.
Define your data validation criteria before the migration starts: which data elements need to match exactly, which can have defined tolerance bands, and which require sign-off from finance and sales operations before go-live can be approved. Build the validation queries that will test those criteria in a sandbox environment first, so that when you run them against real migration data, the framework is proven rather than being tested for the first time under time pressure.
If your core ICM team's scripting background is Oracle PL/SQL, the Groovy learning curve is real and takes time to build genuine proficiency. Groovy for SAP Advanced Workflow is not just syntax — it involves understanding the SAP ICM object model, the execution context of workflow steps, and how Groovy interacts with the commission engine's calculation pipeline. Starting that learning now, on non-critical development work, means your team arrives at the migration project with working Groovy knowledge rather than learning it under production pressure.
The window is narrowing — but it is still open
The migration wave is underway. The consultants who know this domain best are being absorbed into projects faster than new ones are being trained up. HANA infrastructure costs are rising as demand outpaces supply. The organisations that will come through this period in the strongest position are those that treated the 2025–2026 window as preparation time, not deferral time.
For ICM teams specifically, the preparation work is concrete and actionable — it is not a matter of waiting for the technology to mature or the methodology to improve. The schema inventory, the PL/SQL mapping exercise, the data validation framework design, the Groovy upskilling — all of these can start now, with the team you already have, against the systems you already run. The organisations that do this work now will arrive at their migration projects with a headstart that translates directly into faster timelines and fewer crisis escalations.
The ones that don't will be discovering their CS_ table dependencies at 11pm during a go-live weekend in 2027, competing for emergency support from consultants who are triple-booked on other migrations.
SAP HANA vs Oracle: A Practitioner's Comparison
Before planning your migration, understand the architectural differences between Oracle's row-store engine and SAP HANA's columnar in-memory model — and why those differences matter specifically for commission processing workloads.