Changing affiliate platforms is easy to describe: connect the new system, send partners their links and pick a launch date. The difficult part is explaining an order that began in the old system, appeared in the new one and now seems to owe two commissions. A migration plan needs to answer that question before the first payment review.
Treat the move as three connected handoffs: partner relationships, transaction tracking and financial records. Give each an owner, test the overlap between systems and keep unresolved balances visible. The new dashboard being available is one milestone. A program your team can reconcile and your partners can use is the outcome.
Start with the balances you still owe
Consider a fictional program planning a November 1 cutover. Its old platform shows $12,000 in approved commissions, $800 pending review and a $300 disputed adjustment. These figures are a working example, not a vendor balance or an industry benchmark.
Moving $12,000 into a new payment worksheet leaves two questions open: what will happen to the pending $800, and does the $300 adjustment increase or reduce an amount owed? Do not add them into a single “migration balance” until the responsible team has resolved their meaning. A disputed amount needs its transaction references, explanation and decision owner.
A useful opening record has three lines. Approved: $12,000, with payment status and supporting transaction references checked by finance. Pending: $800, assigned to the program manager for review under the applicable terms. Disputed adjustment: $300, kept separate until the parties confirm its direction and treatment. The next system should preserve those distinctions even if its labels differ.
Approved also needs context. An approved commission might already have been paid, be included in an upcoming invoice or still await a payment step. Confirm the actual status. Copying an approved amount into a second payable list can create a duplicate liability rather than a clean handoff.
Make one migration record that the team can explain
Before choosing the cutover date, list the current system, proposed system, intended date, responsible people and the evidence needed to proceed. Keep partner and transaction detail in the approved working files, with access appropriate to the information. A shared project summary can point to those files without exposing a complete partner payment export.
The partner mapping should connect the old partner identifier to the new identifier. Include the partner's agreed commission arrangement, active destinations, required reporting and the person confirming the change. Record who is ready, who has a question and who has not confirmed. A spreadsheet of email addresses is not a migration plan.
For transaction records, retain the order reference, partner reference, relevant dates, currency, commission amount, status and evidence of payment or reversal. Ask finance which records support the next payment run. Ask the technical owner how those fields map to the new setup. If a field disappears in the import, explain how the team will retrieve its meaning later.
As a concrete provider example, Awin's invoice guide says its Awin Classic invoice reconciliation uses the invoice period, Validation Date and Approved transaction status. That is a reason to confirm the date and status that govern your own records. It is not a rule that every affiliate platform uses the same billing method.
Write the rule for an order that crosses the cutover
Suppose a partner places a new tracking link on November 1. A customer who clicked the old link on October 31 purchases on November 2. Your plan needs an agreed treatment for that earlier referral, including which record supports credit, which system calculates the commission and who checks for a duplicate.
Do not assume that creating a new link changes the terms attached to an earlier referral. Confirm the applicable treatment with the responsible platform, program and contract reviewers. Write the answer in plain language and keep the supporting reference. If the answer is still unclear, the scenario is unresolved.
A useful test record for that fictional path could read: “Earlier referral, later purchase. Expected credit and payment owner: awaiting confirmation. Duplicate detection: compare the same merchant order reference across both systems. Release decision: do not approve this path until the expected treatment is confirmed and the test matches it.”
An unresolved expected result cannot become a passing test simply because a purchase appeared somewhere. Decide what should happen first, then compare it with what actually happened. That order matters as much as the tracking code.
Test exceptions alongside the normal purchase
Choose a small set of paths that represents how this program operates. Include a new-link purchase, an eligible earlier referral, a cancelled order, a refund and any discount-code or recurring-order scenario that matters to your business. Ask the relevant platform team which authorized test method to use. Keep test transactions distinguishable from genuine partner balances.
For each path, record the test reference, expected partner credit, observed record, commission calculation and final status. Then check the reversal or correction. A successful purchase test cannot establish that a later refund will be handled correctly.
If both systems record the same order, that observation needs investigation. It does not automatically mean the partner was paid twice. Check whether the records create payable commissions, how adjustments are approved and which source will drive the payment run. The practical question is whether the complete process produces the agreed result once.
Keep failures specific. “Old referral not present in the expected report” gives the technical owner something to reproduce. “Tracking looks wrong” sends everyone back to the dashboard. Add the evidence, owner and next check while the test is still fresh.
Give partners a change notice they can act on
Partners need to know what changes for their actual promotions: links, reporting access, commission terms, payment handling, creative assets and the person answering questions. Confirm each point before announcing it. A platform switch does not justify silently changing commercial terms inside an implementation email.
Here is a fictional message after those details have been confirmed: “Hi Alex, we're preparing a platform change for November 1. Please review the replacement links and the list of your placements in the attached approved brief. Can you confirm which placements you can update and flag any links managed by another team? Your current payment-status questions are recorded separately, and Maya will follow up on those. We'll confirm the cutover after testing; please keep the current setup in place until that confirmation.”
The message asks for a useful response and gives uncertainty a place to go. Send each partner the information relevant to their work through your normal authorized relationship process. Do not expose other partners' details in a shared migration sheet.
Prioritize the partners whose active placements would be most disruptive to lose. Confirm actual destinations and promotion schedules, rather than treating a delivered email as proof that every link has changed. Record exceptions such as an article that another editor controls or a scheduled newsletter already locked for production.
Hold a cutover review with three decisions
The program manager confirms which priority partners are ready and who owns the remaining exceptions. Finance confirms the opening balance, payment status and treatment of unresolved amounts. The technical owner confirms that the agreed transaction paths and duplicate checks passed. One green launch ticket should not stand in for all three decisions.
For the fictional program, a useful review might say: “Approved commissions reconciled to $12,000, with paid and unpaid amounts identified. Pending $800 remains assigned for validation. The $300 adjustment is unresolved and excluded from the confirmed opening payable total. Normal purchases and refunds pass; the earlier-referral path is still open. Cutover held until that path has an agreed treatment and passing test.”
That is a responsible operating decision, even if the new platform is ready to accept logins. Move when the evidence supports the change. If a narrower launch is proposed, name the affected partners and paths, the control that makes it workable and who authorizes it. Do not quietly turn a failed full-program test into an unreviewed partial rollout.
Close the old system deliberately
Keep access, export and termination dates in the plan. Before ending access, verify that required reports, invoices, agreements and unresolved exceptions are retrievable in approved storage. Have the appropriate reviewers confirm retention and contractual requirements for this program. There is no useful universal deletion timetable for every agreement and jurisdiction.
Set a review after the first agreed reporting and payment cycle in the new arrangement. Reconcile the same transaction references, investigate partner questions and check whether unresolved balances received their promised follow-up. Keep corrections traceable instead of replacing the original opening record with a cleaner-looking total.
If you are still choosing the operating model, the network versus in-house comparison covers technology fees and management responsibilities. For help organizing the program work, consider Experience Advertising. For research into additional potential partners, AffiliateFinders supports discovery and contact research. Evan Weber founded both businesses; neither service replaces the platform, finance and agreement checks above.
Before booking a cutover meeting, bring one mapped partner, one reconciled balance and one tested exception. If the team cannot explain those three records, give the unresolved questions owners before giving the migration a launch date.