Migrate an affiliate platform without losing commission continuity

Before you begin

Changing tools changes the links, identifiers, rules and operations connecting a partner with remuneration. Migration does not end when a new tag is installed: it must preserve obligations on existing conversions and explain events arriving during the transition.

This is a working plan to adapt to contracts and documented provider capabilities. A rebrand does not always require technical migration; a similar interface does not establish compatible data or integrations.

1. Define scope and owners

List affected programmes, countries, domains, applications and partners. Assign tracking, contracts, data, communication, invoicing and payments to named owners. Define which changes are allowed during preparation and which must wait.

Record contract end, account closure, final export, link cutover and legacy settlement dates. An access deadline requires preserving usable records before closure, rather than just moving new sales.

2. Preserve usable history

Export partners, agreements, links, conversions and commissions with their states and timestamps. Preserve currencies, timezones, approval rules and identifier mappings. Check row counts, totals by state and a sample reconciled with actual business orders.

A downloaded CSV is not proof of reusable data. Open it, describe every field and test reconciliation with the target system. Limit personal data to a justified scope and apply existing access and retention rules.

3. Build the mapping table

Map old partner identifier to new identifier, programme, currency, agreement and link. Identify sub-identifiers, deep links and promotional codes with a business function. Document unsupported fields and decide explicitly how to preserve or replace them.

Distinguish recorded, pending, approved, rejected, invoiced and paid states. Importing a state must not create a new payable action. A previously approved order must not become a second commission during reconciliation.

4. Test links and events together

Prepare real-channel journeys from articles, newsletters, social posts and relevant apps. Check destinations, parameters, partner identifiers and business events. Replay cancellations, partial refunds, duplicate events and refused consent.

If two systems temporarily observe one event, designate which one decides commission. Parallel collection must not produce duplicate payments. Define the treatment of a legacy click followed by a purchase after cutover.

5. Help partners make changes

Give each partner the date, affected scope, replacement link and support route. Distinguish links that remain valid from those that expire. Do not promise automatic redirection without provider confirmation and a successful test.

Prioritise valuable placements, then track replacements, errors and unreachable partners. Measure active links and valid journeys rather than messages sent. Keep stable instructions to avoid conflicting versions.

6. Set cutover and recovery criteria

Agree measurable gates before cutover: successful critical journeys, unique conversions, consistent amounts, readable exports, available owners and a legacy payment procedure. Acceptable differences must be defined and explained per metric; no universal tolerance exists.

Recovery can become impossible after provider closure. Define what remains recoverable: configuration, controlled redirects, exports and manual procedures. A fallback may need to pause new commissions rather than reactivate an inaccessible platform.

7. Close legacy obligations

Reconcile still-open conversions with invoices, payments and late returns. Identify final approval and dispute dates. Preserve evidence needed for disagreements according to applicable obligations.

Close when differences have an owner and a treatment, partners know where to obtain their status, and obsolete access can be removed. Technical retirement does not automatically extinguish remuneration obligations.

Practical answers

Questions to settle before signing