$_ OfferDaemon Trial

Affiliate network migration guide

Move an affiliate network without losing clicks, conversions, or unpaid balances

Moving to new tracking software is not just copying accounts. You need to know which links must stay live, how advertisers will report conversions, what partners are still owed, and when the old platform can be switched off. This guide walks through those decisions in order.

By OfferDaemon Published Reviewed

The rule that protects the migration

Do not switch off the old platform until you can explain where every live link points, how every conversion is reported, and which platform owns each unpaid balance.

1. Decide what you are moving

Start with the reason for the switch. Faster setup, better control, fewer manual checks, or more reliable tracking are useful goals. “Move everything” is not. Decide what must work on the first day and what can stay in a read-only archive.

Write down what must be ready

  • active Offers and the Advertiser records assigned to them;
  • active Publisher and Merchant accounts, access, and agreed rates;
  • tracking domains, live links, landing pages, GEO rules, caps, and routing;
  • advertiser S2S postbacks and publisher notifications;
  • pending or approved conversions and payments that are not finished;
  • historical reports that must remain available for finance, partners, or compliance.

Give each part one owner

Part of the migrationWho should own itWhat they approve
Offers and partner accountsNetwork or affiliate managerAccounts, access, rates, and Offer setup
Links and domainsPerson responsible for trackingLinks open the right landing pages
Advertiser S2S postbacksAdvertiser integration ownerReal test conversions reach OfferDaemon
Balances and paymentsOperations or financeNo balance is lost or paid twice
Final decisionOne named migration leadTraffic can move or must return to the old setup

One person should be allowed to stop the move. That decision should not depend on a group chat while live traffic is at risk.

2. Save the data and unpaid balances

Export the old platform while everything is still accessible. Keep the original files unchanged, note when they were created, and save simple totals you can compare after the move.

Save the information you will need

  • Offers: names, IDs, Advertiser records, landing pages, status, visibility, GEO rules, caps, payout settings, and publisher-specific rate changes.
  • Partners: IDs, status, contact details, account owner, Offer access, payment method, and any restrictions or special agreements.
  • Tracking: domains, link formats, Publisher and Offer IDs, Click IDs, URL placeholders, extra tracking values, routing rules, and fallback destinations.
  • Conversions: Click ID, transaction ID, Offer, Publisher, amount, date, Conversion Status, and Settlement Status.
  • Payments: partner, amount, currency, Payment Status, included conversions, fees, refunds, and manual corrections.

Separate money into three groups

  1. Already paid: keep it as history so it cannot be paid again.
  2. Approved but not yet paid: decide which platform will include it in a future payment.
  3. Already included in an active payment: keep it linked to that payment or cancel the payment deliberately before moving it.

Protect every unpaid balance

Compare the number and value of conversions by Publisher, Offer, currency, Conversion Status, and Settlement Status. If your old platform has already locked conversions into a payment, do not make them freely payable in OfferDaemon as well.

Record tools used by the old platform

Your current setup may use scheduled exports, SFTP, general webhooks, login tools, or outside reporting systems. Record what each tool does and who depends on it. This is a check of the old platform, not a claim that OfferDaemon includes the same integration.

3. Recreate offers, partners, and tracking

Build the new setup from the information you saved. Start with the Offers and accounts that still receive traffic. Historical records can be kept in an archive when importing them would create more risk than value.

Create the business setup first

  1. Create Advertiser records and assign them to the correct Offers.
  2. Create Publisher and Merchant accounts with the right access.
  3. Add default payouts and any Publisher-specific Offer rates.
  4. Recreate landing pages, visibility, GEO rules, caps, and routing where needed.
  5. Add Redirect Domains and confirm which domain each Publisher or Offer should use.

OfferDaemon chooses a Redirect Domain in this order: a Publisher's private domain, an Offer-specific domain, the company default, and finally the system fallback. Check each level before assuming an old link will behave the same way.

Decide what happens to old tracking links

Keeping the same domain does not automatically keep every old link working. The path and values in that link must still match what the new system understands.

  • If the old link already matches: point the domain to the new setup and test it from click to conversion.
  • If it does not match: translate the old link before it reaches OfferDaemon, or give partners a new Tracking Link.
  • If the link appears in paid ads, emails, apps, or printed material: test that placement separately because replacing it may be difficult.

OfferDaemon does not promise to recognize every link format from another platform. Confirm the link plan before changing DNS or sending new links to partners.

How a new OfferDaemon link fits together

A basic Tracking Link identifies the Offer and the Publisher:

https://track.yournetwork.com/click?offer=offer-slug&aff=publisher-id

The advertiser's landing page can receive the Click ID through a URL placeholder:

https://advertiser.example/landing?clickid={click_id}

OfferDaemon replaces {click_id} with the Click ID created for that visitor. The advertiser must return the same value in its S2S postback so the conversion can be connected to the correct click and Publisher.

4. Test conversions and payments

Do not stop after checking that a link opens. Run a complete test: click the link, confirm the advertiser receives the Click ID, send an S2S postback with the same value, check the result in Postback Log, and confirm the conversion appears under the correct Offer and Publisher.

Test the full conversion path

  1. A visitor clicks the Publisher's Tracking Link.
  2. OfferDaemon creates a Click ID and sends the visitor to the advertiser.
  3. The advertiser saves that Click ID with the visit or order.
  4. When the conversion happens, the advertiser sends an S2S postback containing the same Click ID.
  5. OfferDaemon checks the Click ID and Offer rules, records the request in Postback Log, and creates the conversion when it is valid.
  6. If the Publisher uses an external tracker, OfferDaemon sends a publisher notification with the agreed values.
What to testWhat you should see
Tracking LinkThe correct landing page, Offer, Publisher, and extra tracking values
Advertiser S2S postbackOne conversion connected to the correct Click ID
The same S2S postback sent twiceNo second payable conversion
Refund or reversalThe expected negative event or status change
Publisher notificationThe Publisher's tracker receives the agreed conversion values
Publisher-specific rateThe correct payout is used for that Publisher and Offer
Conversion reviewPending, Approved, and Rejected work as expected
Payment requestOnly eligible conversions enter the payment once
Account accessAdmin, Publisher, and Merchant users see only the information allowed for their role

Keep the three payment decisions separate

  • Conversion Status answers: is this conversion accepted?
  • Settlement Status answers: is this earning still available, locked in a payment, or already settled?
  • Payment Status answers: is the payment Requested, Approved, Processing, Paid, Rejected, or Cancelled?

A Publisher or Merchant can request a payment, and an Admin can generate one. OfferDaemon does not run payments from an automatic payout schedule, so agree who will review and move each payment through the process. The affiliate payout workflow guide explains this in more detail.

5. Move traffic with a fallback plan

Partners should receive only the instructions that apply to them. Some need a new login, some need new links, and others do not need to change anything.

Group partners by the action they need to take

  • No action: links continue to work and the partner only needs to know where to find reports or support.
  • Login action: activate the new account and confirm Offer access.
  • Tracking action: replace links or update the Publisher's external tracker.
  • Payment action: confirm the payment method or an outstanding balance.
  • Custom setup: coordinate any API or outside system that the partner depends on.

Give partners a clear deadline, one contact person, and a simple way to report a broken link or missing conversion. Networks with custom partner setups should contact those partners earlier.

Pause changes before traffic moves

For a short period, stop changes that would make your saved data outdated. This can include new Offers, new Publisher IDs, rate changes, routing edits, S2S postback changes, or payment actions. Record any urgent exception in both systems.

Move a small part of traffic first

  1. Save the final data from the old platform and compare the totals again.
  2. Confirm accounts, Offers, rates, domains, links, S2S postbacks, and publisher notifications in OfferDaemon.
  3. Record current DNS settings before changing a tracking domain.
  4. Move one representative domain, Offer, or small share of traffic first when your setup allows it.
  5. Run the full click and conversion test again.
  6. Move the remaining traffic only after the first part works as expected.

Write down when traffic must return to the old setup, who makes that decision, and how links, domains, and advertiser reporting will be restored. Keep the previous settings ready until the new system is stable.

6. Verify before closing the old platform

A successful first click is not enough. Keep the old platform available in read-only mode until OfferDaemon has completed at least one full conversion review and payment cycle.

  • Compare clicks, conversions, and amounts every day by Publisher and Offer.
  • Check Postback Log for rejected or repeated advertiser S2S postbacks.
  • Confirm Publishers can log in, access the right Offers, create links, see conversions, and understand their balance.
  • Review Pending conversions and confirm Approved and Rejected decisions behave as expected.
  • Complete the first payment and confirm conversions move from Unsettled to Locked and then Settled at the right time.
  • Resolve every missing link, account, conversion, or balance before retiring the old platform.

Once those checks are complete, save the final archive, document who can access it, revoke unused credentials, and ask advertisers to remove old S2S postbacks.

Printable affiliate network migration checklist

Add a name and due date to each item in your project tracker. The boxes show what is finished, while exports, screenshots, and test results provide the proof.

1. Decide what to move

2. Save data and balances

3. Rebuild tracking

4. Test conversions and payments

5. Move traffic safely

6. Verify before shutdown

How OfferDaemon supports the move

OfferDaemon gives your team one place to rebuild Offers, Publisher and Merchant accounts, Tracking Links, Redirect Domains, advertiser S2S postbacks, conversion review, and payment records. It does not pretend that every legacy link or source-platform field can be recognized and imported automatically.

The Enterprise pricing table includes dedicated onboarding and migration support. Agree the exact scope with OfferDaemon before deciding which exports, link changes, or partner communications your team will handle.

Plan the move with OfferDaemon

Bring your current links, postback setup, and open balances

We can review how your network works today, what OfferDaemon can replace, and what needs a separate transition plan. You will leave with a clearer migration scope, not a vague one-click promise.

Related guides