Key takeaways
- Modernizing a legacy SPM system is a program with six phases, and the assessment phase decides whether the rest goes well.
- Replace, re-platform, and augment are all legitimate answers, and the right one depends on where the legacy pain actually lives.
- Open balances such as draws, clawback exposure, held payments, and year-to-date accumulators are the riskiest part of any migration.
- A parallel run only proves something when every variance is explained at the payee and component level and signed off.
- Governance and audit trail design belong in the target state from day one, not in a phase two that never arrives.
Modernizing a legacy SPM system means moving incentive compensation onto an architecture you can change, audit, and trust, without missing a pay cycle. The program runs in six phases: assess the current state, choose to replace, re-platform, or augment, design the target state, migrate plans and data, prove the result in a parallel run, and build governance and an audit trail in from the start.
This guide is the how. If you are still deciding whether you need to modernize at all, start with the signs your enterprise SPM needs modernization and why legacy SPM breaks global sales teams. This guide assumes the case is made and the question is how to execute.
What counts as a legacy SPM system
A legacy SPM system is not defined by age. It is defined by what it costs you to operate and change. Common forms include:
- Spreadsheet estates: commissions calculated in workbooks maintained by one or two people, with logic that lives in cell formulas and memory.
- Homegrown engines: SQL procedures or custom applications written years ago, often by people who have since left.
- Aging commercial platforms: an SPM product on an older generation, or a vendor stack whose support is winding down.
- Mis-architected implementations: a current-generation platform configured so badly that every cycle runs on manual overrides.
The last category matters because it changes the answer. A sound platform with a broken implementation does not need replacing; it needs rebuilding. That distinction is the main output of the assessment.
Phase 1: Assess the current state
The assessment answers one question: where does the pain actually live? It might be in the engine, in the data feeding it, in the plan designs, in the process around it, or in the people who run it. Each answer points to a different program.
Capture the following before anyone talks about vendors.
| Area | What to capture | Why it matters |
|---|---|---|
| Plans | Every active plan, its components, rate tables, caps, accelerators, and the population on it | Plan count and component complexity drive build effort more than headcount does |
| Data feeds | Sources for bookings, billings, hierarchy, HR events, and FX, with owner and refresh timing | Most calculation errors start upstream of the engine |
| Overrides and adjustments | Volume of manual adjustments per cycle, who makes them, and why | High override volume signals a logic or data defect, not a people problem |
| Shadow spreadsheets | Every workbook that touches a payout outside the system | These hold undocumented logic that must be migrated or retired |
| Integrations and outputs | Payroll files, accrual journals, statements, reports, and their consumers | Downstream consumers define what the new system must produce |
| Controls | Who can change plans, data, and payouts, and what evidence exists | Gaps here become audit findings later |
| People and knowledge | Who knows how each plan really calculates | Key-person dependency is a migration risk on its own |
Two practices make the assessment honest. First, trace a sample of real payouts from source transaction to payroll line, including at least one disputed payout. Second, interview the people who make manual adjustments, because they know where the system is wrong.
In one Lanshore assessment, a medical device manufacturer brought us in to evaluate replacing a legacy Callidus system that was blamed for wrong payouts. The engine was calculating correctly. The errors came from a nightly territory feed that overwrote manual reassignments, and from a plan-change process with no effective dating. We recommended fixing the feed and introducing versioned plan changes first, and sequencing the platform replacement after that. That took the "the system is broken" argument off the table.
Phase 2: Decide replace, re-platform, or augment
There are three legitimate answers, and the right one follows from the assessment. For a deeper treatment of the economics, see SPM build vs. buy in the agentic AI era.
| Option | What it means | When it fits | Main risk |
|---|---|---|---|
| Replace | Implement a new SPM platform and retire the legacy engine | The engine cannot model your plans, cannot scale, or is reaching end of support | Underestimating plan rationalization and data migration |
| Re-platform | Move to the vendor's current-generation product, or rebuild the implementation cleanly on the platform you own | The platform is capable but the implementation or product generation is the problem | Porting old workarounds into the new build |
| Augment | Keep the engine and add what it lacks: audit logic, reporting, workflows, agents | The engine calculates correctly and the pain sits around it | Layering new tools on an engine that is quietly wrong |
Some practical tests help:
- If most manual adjustments trace to bad data, replacing the engine will not fix them. Fix the data feeds first and consider augmenting.
- If the plans cannot be expressed in the engine without workarounds, re-platforming on the same product will reproduce the workarounds. Replace.
- If the engine is reaching end of support, the decision is forced, but the choice of destination is not. Teams on the legacy Callidus-based SAP Commissions stack, for example, are being moved by SAP to SAP SuccessFactors Incentive Management, which SAP describes as a reimplementation. That makes it an upgrade or migrate decision that deserves the same evaluation as any other replacement.
- If audit, transparency, and cost modeling are the gaps, augmenting is often enough. In one Lanshore engagement, a fast-growing software vendor needed audit capability, transparent reporting, and comp cost modeling without ripping out its existing systems. The team extended the existing SPM setup with audit-ready calculation logic, reporting for reps and finance, and cost modeling for planning (case study).
Rebuilding can also be the right call. In another engagement, a commission process had been broken for over a year, with payments going out on manual overrides. The fix was redesigning the SPM architecture from the plan document down, rebuilding crediting and calculation logic, removing the override layer, and re-establishing a controlled monthly cycle (case study).
If you choose to replace, run the platform evaluation against your own plans and data, not vendor demos. Our guide to choosing SPM software covers how.
Phase 3: Design the target state
The target state is not the legacy system on new infrastructure. Modernization is the one moment when the organization will tolerate changing how plans are built, so use it.
Rationalize plans before you build them
List every plan variant and ask why it exists. Variants that differ only in a rate or a quota can usually collapse into one plan template with parameters. Components that nobody can explain, or that pay small amounts at high administrative cost, are candidates for retirement. Every plan you do not migrate is one you do not have to build, test, reconcile, or audit.
Write plans as rules, not formulas
Document each plan as business rules in plain language: what is credited, to whom, when, at what rate, with which exceptions. Then build from the rules. Copying legacy formulas cell by cell ports every historical mistake into the new system.
Design the data model around effective dates
Hierarchies, territory assignments, crediting splits, and rate tables all change mid-period. The target state needs effective-dated records for each, so a transfer, a leave, or a territory change calculates correctly without a manual adjustment. Our incentive compensation data governance guide covers ownership and quality rules for these feeds.
Define outputs by consumer
Payroll, finance accruals, rep statements, manager dashboards, and audit exports each have a consumer with requirements. Write those requirements down and test against them.
Phase 4: Migrate plans and data
Migration has three distinct workstreams, and the third is the one teams underestimate.
Plan logic
Build each rationalized plan in the target system from its rules document. Create test cases from real edge cases, not idealized ones:
- Mid-period hires, terminations, and transfers between plans or territories
- Leaves of absence and return-to-work proration
- Split credits across reps, overlays, and channel partners
- Cancellations, rebills, and credit memos that reverse prior credit
- Currency conversion for multi-currency payees
- Caps, decelerators, and thresholds crossed mid-period
Historical data
Migrate the history the new system needs to calculate: prior-period values for growth or year-over-year components, the clawback lookback window, and the period during which disputes and prior-period adjustments can still arrive. Archive the rest in a read-only, queryable store with a retention period agreed with finance and legal.
Open balances
Open balances are money already owed in one direction or the other, and they must carry over exactly:
- Recoverable and non-recoverable draw balances
- Outstanding clawback or chargeback exposure
- Held or deferred payments
- Year-to-date attainment and accumulators for tiered, capped, or annual components
- Accrual balances that finance has already booked
A plan-year boundary is the cleanest cutover point because accumulators reset. A mid-year cutover is workable, but every open balance must be loaded and reconciled to the legacy figures, payee by payee, before the first live cycle.
When the legacy source is a spreadsheet estate, migration is also change management. In one Lanshore engagement, variable pay was administered in Excel and errors were eroding rep trust, but the team was wary of change. The work combined a platform sized to the plans, migration of the spreadsheet logic, and change management for admins and reps (case study).
Phase 5: Run in parallel and reconcile
A parallel run calculates the same period in both systems from the same inputs and compares the results. It is the only evidence that the new system is ready.
Compare at the right grain
Compare at the payee and component level, not at total payout. Totals can match while individual payees are wrong in offsetting directions. Compare statements, payroll files, and accrual outputs, not only calculation results.
Classify every variance
Each variance falls into one of four categories, and each needs an owner and a disposition:
- Legacy error: the old system was wrong. Document it and decide with finance whether a correction is owed.
- New system defect: fix it and re-run.
- Intentional design change: a result of rationalization. Confirm it was approved and communicated.
- Timing or data difference: the systems received different inputs. Fix the feed and re-run.
Set exit criteria before you start
Agree the exit criteria up front: every variance classified and dispositioned, all defects fixed and re-tested, outputs accepted by payroll and finance, and written sign-off from the compensation owner and the finance controller. Include at least one cycle that exercises quarter-end or other periodic components if your plans have them, because monthly-only parallels miss those paths.
For example, when Grammarly moved off spreadsheets, Lanshore needed one parallel-run cycle before sign-off. The variances fell into three categories: crediting dates (the spreadsheet used order date, while the platform used booking date as the plan specified), rounding on tiered rates, and one SPIF that had been paid manually outside the spreadsheet. All three were resolved in that cycle and cutover proceeded. Enterprise migrations typically need two to three cycles.
Phase 6: Build governance and the audit trail in
A modernized system that cannot answer an auditor's question is not modern. Design these into the target state rather than adding them later:
- Plan change log: who changed which rule, the effective date, and the approval reference.
- Adjustment register: every manual adjustment with a reason code, the person who entered it, and the approver, kept separate.
- Data lineage: which load, from which source, at which time, fed each calculation.
- Statement versions: every statement issued to a payee, including restatements.
- Acknowledgments: which payee accepted which plan document and when.
- Role separation: the person who configures plans is not the person who approves payouts.
The decision rights and policies behind these controls are covered in our global incentive governance guide. The analytics that make them reviewable are covered in enterprise SPM consulting for audit-ready analytics.
Where AI agents fit in a modernization program
AI agents are useful during and after modernization, provided they work under human supervision with a full audit trail.
During migration, agents can:
- Validate each data load against expected volumes, keys, and value ranges before calculation
- Compare parallel-run outputs line by line and propose a variance category for a human to confirm
- Draft plain-language documentation of legacy rules from existing configuration, for an analyst to verify
After go-live, agents can run the recurring cycle: scheduled data loads, calculation runs, validations, and exception queues, with errors routed to a person with a suggested fix. This is the SPM Operations pillar of Agentic SPM by Lanshore, where every agent action is logged with timestamp, input, output, and approver where applicable. The SPM Operations demo includes an Xactly-to-Varicent migration mode.
Where agents should not act alone: plan design, approval of exceptions and overrides, and release of payouts. A named person approves anything that reaches payroll. Agents also amplify whatever they are pointed at, so they belong on top of clean hierarchies and correct plan logic, which is one more reason the earlier phases matter.
Cutover and the first cycles after go-live
Cutover is a scheduled event with a rollback plan, not a switch flipped on a Friday. A workable sequence:
- Freeze plan changes in the legacy system after the final parallel cycle.
- Load and reconcile final open balances.
- Run the first live cycle with the legacy system available for comparison.
- Hold a hypercare period with daily triage of exceptions and inquiries.
- Retire the legacy system only after archive access is confirmed and finance signs off.
Communicate with payees before the first new statement arrives. A statement that looks different, even when it is correct, generates inquiries. Our guide to preventing incentive compensation disputes covers statement design and inquiry handling.
Common modernization mistakes
- Choosing the platform before the assessment. The vendor decision is the last part of Phase 2, not the first.
- Migrating every plan variant. Rationalization is cheaper before the build than after.
- Treating open balances as a data load. They are financial obligations and need reconciliation and sign-off.
- Comparing totals in the parallel run. Offsetting errors hide at the total level.
- Deferring governance to phase two. Retrofitting controls is harder than designing them in.
- Losing the people who know the legacy logic. Document their knowledge before the project needs it.
Lanshore has also been brought in to recover from one. At Micro Focus, in work delivered with PwC, an SAP Sales Cloud (CallidusCloud) rollout had stalled after a go-live with unreconciled results. Recovery involved rebuilding the crediting and quota data model, re-running the prior periods in parallel against the old results, and standing up a release process with sign-off per cycle before the client would trust the numbers.
How Lanshore helps
Lanshore has implemented sales performance management for enterprises for more than 15 years, with delivery across the US and Latin America. We implement and operate nine SPM platforms, including migrations onto Varicent from Xactly, SAP Commissions, and spreadsheet estates, and migrations in either direction involving Xactly. We are platform-neutral and resell none of them. After go-live, we can run comp operations as a managed service, increasingly with agents handling the repetitive work and our team handling judgment calls.
Frequently asked questions
How long does it take to modernize a legacy SPM system?
It depends on the number of plans, the quality of the source data, and whether you replace, re-platform, or augment. An augmentation that adds audit, reporting, or agents around an existing engine is usually the shortest path. A full replacement is the longest because it needs plan rationalization, data migration, and at least one clean parallel run before cutover. Scope the timeline after the assessment, not before.
Should we cut over to a new SPM system mid-year?
A plan-year boundary is the cleanest cutover point because tiered rates, caps, and annual accumulators start fresh. A mid-year cutover is workable, but every year-to-date accumulator, open draw, held payment, and clawback exposure must be loaded into the new system and reconciled to the legacy figures before the first live cycle runs.
How much historical compensation data should we migrate?
Migrate the history the new system needs to calculate correctly: prior-period values used by growth or year-over-year components, the lookback window for clawbacks, and the window in which disputes and prior-period adjustments can still arrive. Archive older history in a read-only, queryable store with a documented retention period agreed with finance and legal.
What is the difference between replacing and augmenting an SPM system?
Replacing means implementing a new SPM platform and retiring the legacy engine. Augmenting means keeping the calculation engine you already own and adding what it lacks, such as audit-ready logic, transparent reporting, approval workflows, or AI agents that run the cycle. Augmenting fits when the engine is sound and the pain sits around it.
Can AI agents help with an SPM migration?
Yes, within limits. Agents are useful for validating data loads, comparing parallel-run outputs line by line, classifying variances for a human to confirm, and drafting documentation of legacy rules for review. They should not decide plan design or release payouts. A named person approves anything that reaches payroll, and every agent action is logged.
See how this works in practice in the three pillars of AI Assisted SPM by Lanshore: Executive Dashboards, SPM Operations, and Custom Apps.
Get new SPM & agentic AI posts by email
Occasional notes from Lanshore. No spam, unsubscribe anytime.