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 migration | Who should own it | What they approve |
|---|---|---|
| Offers and partner accounts | Network or affiliate manager | Accounts, access, rates, and Offer setup |
| Links and domains | Person responsible for tracking | Links open the right landing pages |
| Advertiser S2S postbacks | Advertiser integration owner | Real test conversions reach OfferDaemon |
| Balances and payments | Operations or finance | No balance is lost or paid twice |
| Final decision | One named migration lead | Traffic 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
- Already paid: keep it as history so it cannot be paid again.
- Approved but not yet paid: decide which platform will include it in a future payment.
- 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
- Create Advertiser records and assign them to the correct Offers.
- Create Publisher and Merchant accounts with the right access.
- Add default payouts and any Publisher-specific Offer rates.
- Recreate landing pages, visibility, GEO rules, caps, and routing where needed.
- 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
- A visitor clicks the Publisher's Tracking Link.
- OfferDaemon creates a Click ID and sends the visitor to the advertiser.
- The advertiser saves that Click ID with the visit or order.
- When the conversion happens, the advertiser sends an S2S postback containing the same Click ID.
- OfferDaemon checks the Click ID and Offer rules, records the request in Postback Log, and creates the conversion when it is valid.
- If the Publisher uses an external tracker, OfferDaemon sends a publisher notification with the agreed values.
| What to test | What you should see |
|---|---|
| Tracking Link | The correct landing page, Offer, Publisher, and extra tracking values |
| Advertiser S2S postback | One conversion connected to the correct Click ID |
| The same S2S postback sent twice | No second payable conversion |
| Refund or reversal | The expected negative event or status change |
| Publisher notification | The Publisher's tracker receives the agreed conversion values |
| Publisher-specific rate | The correct payout is used for that Publisher and Offer |
| Conversion review | Pending, Approved, and Rejected work as expected |
| Payment request | Only eligible conversions enter the payment once |
| Account access | Admin, 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
- Save the final data from the old platform and compare the totals again.
- Confirm accounts, Offers, rates, domains, links, S2S postbacks, and publisher notifications in OfferDaemon.
- Record current DNS settings before changing a tracking domain.
- Move one representative domain, Offer, or small share of traffic first when your setup allows it.
- Run the full click and conversion test again.
- 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
- Write why you are switching and what must work on the first day.
- List active Offers, partners, links, S2S postbacks, open conversions, payments, and required history.
- Name one owner for partner data, tracking, advertiser reporting, balances, and the final move decision.
- Decide which information will move and which will remain in a read-only archive.
2. Save data and balances
- Save original exports of Offers, accounts, tracking settings, conversions, and payments.
- Record when the exports were created and keep them unchanged.
- Separate paid history, approved but unpaid conversions, and conversions locked in active payments.
- Compare counts and amounts by Publisher, Offer, currency, Conversion Status, and Settlement Status.
- List any outside tool or integration used by the old platform and who depends on it.
3. Rebuild tracking
- Create Advertiser records, Offers, Publisher accounts, and Merchant accounts.
- Recreate Offer access, landing pages, rates, GEO rules, caps, and routing.
- Add Redirect Domains and confirm the correct domain is selected for each link.
- Choose whether each old link will keep working, be translated, or be replaced.
- Check that the Click ID reaches the advertiser through the expected URL placeholder.
4. Test conversions and payments
- Test a complete click and advertiser S2S postback with the same Click ID.
- Check the result in Postback Log and confirm one correct conversion is created.
- Test a repeated S2S postback, refund, publisher notification, and Publisher-specific rate.
- Check account access for Admin, Publisher, and Merchant users.
- Review Conversion Status, Settlement Status, and the full Payment Status process.
5. Move traffic safely
- Tell each partner whether they need to change a login, link, tracker, or payment detail.
- Pause Offer, partner, rate, routing, S2S postback, and payment changes for a short agreed period.
- Save current DNS and tracking settings so they can be restored.
- Move a small part of traffic first and run the complete conversion test again.
- Write down when traffic must return to the old setup and who makes that decision.
6. Verify before shutdown
- Compare clicks, conversions, and amounts every day by Publisher and Offer.
- Check partner access, Tracking Links, Postback Log, and unpaid balances.
- Complete one full conversion review and payment cycle in OfferDaemon.
- Resolve every missing link, account, conversion, or balance.
- Save the final archive and remove old access and S2S postbacks only after approval.
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.