Affiliate platforms: questions to ask before you migrate (SaaS)

Migrating affiliate software is less about ‘features’ and more about **ledger integrity**. If you can’t reconcile the old system’s numbers (conversions, adjustments, refunds, and payouts), the new system won’t magically fix it — you’ll just move the confusion.

Use this page as a pre-migration checklist. The goal: keep commissions explainable, avoid double-paying (or under-paying), and make sure affiliates don’t lose trust during the switch.

Table of contents

• Start with the ledger, not the UI
• Export checklist (what you must get out)
• Attribution + tracking questions
• Refunds, chargebacks, and clawbacks
• Payout ops (how you’ll actually pay)
• Cutover plan (safest timeline)
• FAQ

Start with the ledger, not the UI

A migration is successful if you can answer these two questions on day 1 in the new platform: **(1) why was this commission earned?** and **(2) why is this payout amount correct?** If you can’t, pause and fix your data story first.

• Affiliate platform vs affiliate software (pillar)
• Affiliate reporting metrics that matter

Export checklist (what you must get out)

• A full conversion ledger (every conversion event + timestamp + amount + currency).
• All adjustments (manual edits, reversals, bonuses) with reasons.
• Affiliate identities (email, payout details if stored, status).
• Link/coupon mappings (which partner used which identifier).
• Payout history (paid / pending / failed) and payout method used.
• Refund/chargeback events linked to invoice ids (or whatever your billing system uses).

If the vendor can’t export a complete ledger, treat it as a red flag. You may still migrate, but you’ll need a manual reconciliation plan and you should expect disputes.

Attribution + tracking questions

• What counts as a conversion: signup, trial start, first paid invoice, renewal?
• How does the platform dedupe: cookie, coupon, email domain, or server-side events?
• What is the attribution window and where is it enforced (browser vs server)?
• How are deep links handled and restricted?
• Can you trace each conversion back to a billing object (invoice/subscription id)?

• Cookie vs coupon vs email matching
• How affiliate tracking breaks (debugging)
• Deep links: handle safely

Refunds, chargebacks, and clawbacks

Most migration pain comes from refunds. Decide your refund policy first, then encode it. If you migrate without a clawback workflow, you’ll end up with ‘negative balances’ you can’t explain.

• Refunds + commissions: clawback workflow
• Chargebacks + commissions

Payout ops (how you’ll actually pay)

• Can you keep payouts manual + batched while you validate the new ledger?
• Can you export a payout CSV that matches your accounting needs?
• Do you support payout holds for new affiliates or suspicious activity?
• What happens to affiliates with missing payout details?

• Affiliate payouts: audit checklist

Cutover plan (safest timeline)

If you can’t run in parallel, pick a clean boundary date and communicate it clearly to affiliates (what will be tracked where, and for how long).

FAQ

Do we need to migrate historical data?

You need historical data somewhere, but not necessarily inside the new tool. The minimum is a read-only export you can query to answer disputes.

What’s the #1 question that predicts migration success?

‘Can we trace every commission to an invoice id and explain adjustments?’ If yes, you’ll be fine. If no, expect ongoing ops pain until you fix that link.

Related pages

• Affiliate payout rules template
• Affiliate clawback policy template
• Affiliate payouts CSV export
• Affiliate tracking debugging guide
• Affiliate payout audit checklist