From Callidus Commissions to SAP SuccessFactors IM: What Changed

The Acquisition: Why SAP Bought Callidus

In August 2018, SAP announced it was acquiring Callidus Cloud (formerly Callidus Software, Inc.) for approximately $2.4 billion. This was a strategic move. SAP's product portfolio had SuccessFactors (HR, talent management, payroll), but it lacked a modern Incentive Compensation Management (ICM) solution. The SAP industry was fragmented: customers used disparate tools (Callidus, Anaplan, Certent, homegrown systems) for commissions and compensation. SAP wanted to own that space.

Callidus had a mature platform: it ran compensation for thousands of global enterprises, it was cloud-based (rare in 2018 for enterprise software), and its user base was sticky (switching costs are high). For Callidus customers, the acquisition meant stability — SAP support, SAP engineering, SAP's financial backing. For SAP, it meant instant market leadership in ICM.

The post-acquisition strategy was clear: keep Callidus running as-is for support continuity, but begin a multi-year effort to integrate it into the SuccessFactors ecosystem and rebuild it on SAP's modern platform (HANA, Fiori, REST APIs).

What Carried Over from Callidus

SAP didn't tear down Callidus and rebuild from scratch. That would have killed the product and alienated customers. Instead, they preserved the core concepts and gradually modernized the implementation.

Core Compensation Concepts

The fundamental ICM model stayed unchanged:

• Plans: Compensation structures with periods, rules, and participants. CS_COMP_PLAN → CSC_COMP_PLAN (same table model, HANA-optimized).
• Participants: People who earn. CS_PARTICIPANT → CSC_PARTICIPANT (same schema, same hierarchy concept).
• Pipeline: Import, Classify, Credit, Calculate, Summarize, Statement — same six stages, same logic. CSC_CREDIT, CSC_RESULTS, CSC_STATEMENT follow the same naming and purpose.
• Calculation engine: The plan's compensation logic (commission percentage, quota attainment curves, SPIFs, overrides). This concept transferred directly. The implementation language changed (from proprietary Callidus script to SAP's modern rules engine), but the mental model is identical.
• Results and payouts: Same output — compensation statements fed to payroll. Same audit trail, same approval workflows.

Workflow Concept

Callidus Workflow — an event-driven workflow engine — was preserved in concept. In SAP SuccessFactors IM, the equivalent is SAP Advanced Workflow. The idea is the same: trigger actions based on pipeline events (result calculated → send to manager for approval → approved → feed to payroll). The implementation is new (SAP's workflow framework instead of Callidus's), but the pattern is unchanged.

What Changed: The Four Big Shifts

1. Database: Oracle → SAP HANA

Callidus ran on Oracle Database. SAP SuccessFactors IM runs on SAP HANA, SAP's columnar, in-memory database. This is a significant change at the SQL level.

Why the change? HANA is in-memory, which means compensation calculations (which require aggregations across large result sets) are dramatically faster. It's columnar, optimized for analytical queries. And it's SAP's strategic platform — all SuccessFactors runs on HANA, so it's a unification play.

For practitioners, this matters because:

• SQL syntax is similar but not identical. HANA SQL is Oracle-compatible in most cases, but there are differences. Some functions are renamed (e.g., TRUNC → DATE_TRUNC), some aggregate functions behave differently.
• Query optimization is different. HANA doesn't have the same index types as Oracle. You might have fast full-table scans on HANA where Oracle would use an index. Query plans are different.
• Bulk operations are fast. HANA's columnar design makes bulk INSERT, UPDATE, DELETE much faster. This helps with pipeline performance.

2. Data Model: CS_ Tables → CSC_ Tables

The table naming changed. All CS_ tables were prefixed with CSC_ (Callidus → SuccessFactors migration). The schemas were redesigned for HANA optimization — some tables were denormalized, some were split.

• CS_COMP_PLAN → CSC_COMP_PLAN
• CS_PARTICIPANT → CSC_PARTICIPANT
• CS_CREDIT → CSC_CREDIT
• CS_RESULTS → CSC_RESULTS
• CS_STATEMENT → CSC_STATEMENT

The 1:1 mapping makes migration straightforward: migrate data from CS_ to CSC_, rewrite queries from Oracle SQL to HANA SQL, test, and cutover. The hardest part is usually the calculation logic — if you have custom Callidus rules, those must be ported to SAP's rules engine.

3. User Interface: Callidus UI → SAP Fiori

Callidus had a proprietary web UI. SAP rebuilt the entire UI in SAP Fiori, SAP's design system. Fiori is browser-first, mobile-friendly, and consistent across SAP products.

For end users, this is a dramatic change: different look, different navigation, some features in different places. For admins and analysts, it's still a web application — you log in, see your plans, run your pipeline, review results. The core workflows are the same, just with a modern skin.

For reporting, Callidus had built-in dashboards. SAP SuccessFactors IM integrates with SAP Analytics Cloud (SAC) for dashboarding and BI. This is more powerful but requires a shift from Callidus's dashboard builder to SAC's design experience.

4. Integration: Standalone → Ecosystem Player

Callidus was standalone — you fed it data, it calculated compensation, you extracted results. SAP SuccessFactors IM is embedded in an ecosystem:

• SuccessFactors HCM: Direct integration with employee records, organizational hierarchy, position data. No more syncing from a separate HR system — HCM is the source of truth.
• S/4HANA: Sales and financial data flowing from ERP directly to IM. Real-time or near-real-time pipeline runs instead of nightly batch jobs.
• Sales Cloud: Opportunity data, pipeline, forecast directly feeding compensation calculations.
• Payroll (through HCM): Compensation statements feed directly to payroll via SuccessFactors Payroll.

This ecosystem approach is powerful but requires rethinking your data architecture. Instead of ETL pipelines pulling data from multiple sources, you're now synchronizing with SAP's master data platforms.

Migration Decision Framework

Not every Callidus customer migrated immediately. SAP supported Callidus in parallel with SuccessFactors IM for years (the support window is now closing). You should migrate when:

• Contract renewal. Your Callidus support contract comes up for renewal. Migrate to SuccessFactors IM instead of renewing. This is usually the trigger — it forces a decision.
• Major plan redesign. You're rearchitecting your compensation plans (new commission structure, new business model). Instead of redesigning in Callidus, do it in SuccessFactors IM.
• SuccessFactors HCM deployment. You've just deployed SuccessFactors HCM for HR. Now migrate IM to the same platform — unified employee data, simplified integration.
• Regulatory or compliance drivers. New GDPR or tax regulations require system upgrades. Might as well migrate to SuccessFactors IM.
• Data volume growth. Your Callidus system has millions of records and queries are slow. HANA's performance is a big win.

You should not migrate just because it's newer. Callidus is stable and fully supported (for now). If your system is humming along and your users are happy, the upgrade effort might outweigh the benefits.

Parallel Run vs. Cutover

Once you decide to migrate, the question is how: parallel run or big-bang cutover?

Parallel Run (Recommended)

Run Callidus and SuccessFactors IM side-by-side for 1-2 periods. Compare results. If results match, flip the switch to IM and retire Callidus. If results differ, investigate and fix. Parallel runs are safer but require double the work during the transition period.

Big-Bang Cutover (Faster But Riskier)

Stop using Callidus, start using SuccessFactors IM immediately. Faster, but if something goes wrong, you're debugging production issues with your finance and sales teams waiting. Only do this if you have high confidence in the migration (you've tested extensively, your data is clean, your calculation logic is simple).

Most enterprises choose parallel run. Compensation is critical — any errors risk overpayment, underpayment, or regulatory violations. Two months of parallel validation is worth the extra effort.

Data Migration: CS_ to CSC_

The migration itself is a data transformation project. You're moving from Callidus (Oracle) to SuccessFactors IM (HANA), and the schema has changed.

1:1 Table Mapping

The good news: most tables map one-to-one. Here's a rough mapping:

-- ORACLE: Date truncation
SELECT TRUNC(created_date, 'MM') -- first day of month
FROM cs_results;

-- HANA: Use DATE_TRUNC instead
SELECT DATE_TRUNC(created_date, 'MONTH')
FROM csc_results;

-- ORACLE: Hierarchical queries
SELECT id, name
FROM cs_participant
CONNECT BY PRIOR id = parent_id
START WITH parent_id IS NULL;

-- HANA: Use recursive CTEs instead
WITH RECURSIVE hierarchy AS (
  SELECT id, name, parent_id
  FROM csc_participant
  WHERE parent_id IS NULL
  UNION ALL
  SELECT p.id, p.name, p.parent_id
  FROM csc_participant p
  INNER JOIN hierarchy h ON p.parent_id = h.id
)
SELECT * FROM hierarchy;

-- ORACLE: String functions
SELECT SUBSTR(name, 1, 10), INSTR(name, ' ')
FROM cs_participant;

-- HANA: Same functions, but also has SUBSTRING
SELECT SUBSTRING(name, 1, 10), LOCATE(name, ' ')
FROM csc_participant;

-- ORACLE: Calculate commission (15% of sales above quota)
SELECT participant_id, period_id, total_sales, quota_amount,
       CASE WHEN total_sales >= quota_amount
            THEN ROUND((total_sales - quota_amount) * 0.15, 2)
            ELSE 0
       END AS commission_amount
FROM cs_credit
GROUP BY participant_id, period_id, total_sales, quota_amount;

-- HANA: Same logic, ROUND behaves slightly differently
SELECT participant_id, period_id, total_sales, quota_amount,
       CASE WHEN total_sales >= quota_amount
            THEN ROUND((total_sales - quota_amount) * 0.15, 2)
            ELSE 0
       END AS commission_amount
FROM csc_credit
GROUP BY participant_id, period_id, total_sales, quota_amount;

-- ORACLE: Tiered commission (0-50% quota = 8%, 50-100% = 10%, >100% = 12%)
SELECT participant_id, total_sales, quota_amount,
       CASE WHEN total_sales / quota_amount < 0.5 THEN total_sales * 0.08
            WHEN total_sales / quota_amount <= 1.0 THEN total_sales * 0.10
            ELSE total_sales * 0.12
       END AS tiered_commission
FROM cs_credit
WHERE quota_amount > 0;

-- HANA: Same logic with NULLIF for safety
SELECT participant_id, total_sales, quota_amount,
       CASE WHEN total_sales / NULLIF(quota_amount, 0) < 0.5 THEN total_sales * 0.08
            WHEN total_sales / NULLIF(quota_amount, 0) <= 1.0 THEN total_sales * 0.10
            ELSE total_sales * 0.12
       END AS tiered_commission
FROM csc_credit;