Switching commission platforms is riskier than buying your first one. The first time, you are replacing a spreadsheet nobody trusted. The second time, you are replacing a system that pays people correctly most months, and any gap between old and new shows up in a paycheck. This guide covers how to plan the move so payroll never notices.
Decide Why You Are Leaving
Write down the two or three specific things the current platform cannot do. "It is clunky" is not a reason a new vendor can solve. "Plan changes take three weeks and a services ticket" is. That list becomes your demo script and your acceptance test.
If the real problem is plan complexity or dirty CRM data, a new platform will inherit it. Fix those first, or at least in parallel. The implementation checklist covers what to clean up before you start.
Pick the Cutover Date First
Work backward from a date, not forward from a signature.
Best: the start of a fiscal year, when new plans begin and there are no year-to-date balances to carry over.
Workable: the start of a quarter, if your plans measure quarterly.
Avoid: mid-period. You will have to load partial attainment, in-flight accelerators, and open draws, and every one is a place to be wrong.
Check your current contract for the renewal date and notice period before you commit to a timeline. Paying for two platforms for a few months is normal. Auto-renewing the old one for a year is not.
What to Move and What to Leave
Move: current plan rules, active participants and their assignments, quotas, open balances such as draws and clawback exposure, and anything that affects a future payout.
Archive, do not migrate: closed-period statements and calculation detail. Export them to storage finance controls. You need to be able to answer a question about last year. You do not need last year recalculating in the new tool.
Rebuild, do not copy: plan logic. Every platform models rules differently. Translating old formulas line by line carries forward every workaround you built to get around the old tool's limits.
Before you rebuild, write each plan in plain language: who is paid, on what event, at what rate, with what limits. If you cannot write it down, you cannot test it.
Run in Parallel
This is the step teams cut when the schedule slips, and it is the one that protects payroll. Run both systems on the same data for at least two full pay periods and compare payouts person by person.
Pay from the old system during the parallel run. The new one is under test.
Set a tolerance before you start. To the cent is the right target for most plans.
Investigate every difference. Some will be bugs in the new build. Some will be errors the old system has been making for months. Decide what to do about those before go-live, not after.
Include the awkward cases on purpose: a mid-period hire, a territory change, a split deal, a clawback, a rep who crossed an accelerator tier.
Illustration: a 40-rep team runs two monthly cycles in parallel. Cycle one shows 9 reps with differences. Six trace to a crediting rule built differently in the new tool, two to a rate table typo, and one to an old-system error on a split deal. Cycle two shows zero differences. That is what ready looks like.
Cut Over
Freeze plan changes for the cutover period.
Load opening balances and have finance sign off on them.
Keep read access to the old platform for at least one full cycle after go-live, longer if your contract allows it.
Tell reps what is changing, when, and where to look. A new statement layout generates questions even when every number is right. What belongs in a statement is a useful checklist for the new layout.
Staff the first payroll. Expect the comp team's time to be fully spoken for that week.
Where Migrations Go Wrong
The timeline assumed clean data. It rarely is.
Nobody owned the plan rules. The implementer built what the old system did, including its mistakes.
The parallel run was one cycle, or none.
History was migrated in full, doubling the scope for little benefit.
The old contract renewed because notice was missed.
Budget for the Full Move
The new subscription is one line. Add implementation fees, overlap with the old contract, internal time for testing, and any outside help. What ICM software really costs breaks down the lines that do not appear on the quote. If you are still choosing where to go, start with how to select an ICM platform and the platform comparison.
A migration is done when two things are true: payouts match, and the people who run the process can explain why. Plan for both.