Affiliate Network Migration Guide: Move Off Everflow, CAKE, or HasOffers Without Losing Data

Migrating an affiliate network feels like performing open-heart surgery on a running business, every click, every postback, every payout is live money.

It doesn’t have to be. The playbook is well-understood, and if you follow it, the migration is invisible to your affiliates and your advertisers.

This is the exact checklist we use at OfferMesh.

TL;DR

Audit the old platform first, you can’t migrate what you haven’t inventoried.
Run both platforms in parallel for 14–30 days before cutover.
Cut over during a low-traffic window (weekday early morning in your busiest region’s dead hours).
Verify daily for the first week, weekly for the first month.
Keep the old platform live for at least 60 days for chargebacks and audits.
Document the rollback plan before cutover, not after something breaks.

When to migrate (and when not to)
Pre-migration audit
Data export by platform
Setting up the new platform
The parallel run
The cutover day
Keep the old platform running
Common pitfalls
Rollback plan
Post-migration verification
Migration cost
FAQ

When to migrate (and when not to)

Not every complaint about a platform is a migration signal. Migrations are expensive and risky; the bar for triggering one should be high. Here’s how we think about the threshold.

Good reasons to migrate:

Cost. Your platform’s minimums scale faster than your revenue. Everflow, CAKE, and Affise all have five-figure annual floors once you cross moderate volume.
Missing features. No S2S postback signing, no fraud scoring, no smart routing, no first-party tracking domain.
Poor support. Ticket SLAs measured in days instead of hours, or account managers who don’t understand your integrations.
Slow redirects. Slow redirects lose 5–10% of conversions. If your platform’s TTFB on tracking hits sits above 200ms, you’re bleeding money.
Platform stagnation. No product updates in six months, roadmap that never ships, a UI last touched in 2018.
Data portability. You can’t get a clean export of your own conversions.

Bad reasons to migrate:

One bad support ticket. Every platform has a bad day.
Feature envy from a demo. Demos always look better than production.
Board pressure to “modernize the stack.” Migrations are risk. Do them because the math works, not because the deck says so.

You should migrate if:

You’ve had a formal SLA breach or a data-loss incident.
Your platform bill grows faster than 1.5x your revenue year-over-year.
You’ve been told a critical feature is “on the roadmap” for more than two quarters.
Your affiliates complain about the dashboard weekly.
Advertiser postbacks fail more than 0.5% of the time.
You can’t get answers about how your own data is stored, backed up, or exported.

Two of six is a warning sign. Four of six is a decision. Six of six is overdue.

Pre-migration audit

You can’t migrate what you haven’t inventoried. The audit is not a formality. Every field you skip here will surface as a broken postback or a payout dispute in the first month after cutover.

Export every one of these from your old platform before you touch the new one:

Offers list, every active and paused offer, including payout terms, caps, geo targeting, and creative assets.
Affiliates list, with contact info (email, Skype, Telegram), tier, payment method, tax status, and any custom tags.
Active tracking links, every published link, in the exact format affiliates are using.
Click history, last 90 days minimum. This is your baseline for reconciliation.
Conversion history, last 12 months at minimum. You need this window for chargeback and clawback reconciliation.
Postback templates per advertiser, the exact URL, method, signature scheme, and macros.
Payout history, the last 12 months, including method, currency, invoice numbers, and any withheld balances.
Custom fields, anything you added to offers, affiliates, or conversions that doesn’t come out of the standard export.
Fraud rule configurations, IP blocklists, device fingerprint rules, velocity thresholds, geo restrictions.
Integration inventory, every third-party tool wired into the platform (BI, ESP, fraud vendor, accounting).

If your export from step 1–4 doesn’t match what the platform’s UI shows, stop and open a ticket. You will not fix that gap after cutover.

Store the raw exports in cold storage (S3 with object lock, or equivalent) for a minimum of seven years. This protects you against future audit requests, chargeback disputes, and any legal discovery around historical affiliate activity.

Do not proceed to platform setup until every item in the list above has been exported, verified against the UI, and archived. This is the single most-skipped step, and the source of most botched migrations.

Data export by platform

The right export path depends on the platform. Each has its own quirks, silent truncation, missing fields, rate-limited APIs, so budget for the longest option, not the shortest.

Everflow

Everflow’s exports live under Reports → Offers, Affiliates, and Conversions, each with CSV export. For anything more than 90 days or more than a few thousand rows, use the API at everflow.io/api/v1/, the UI export is capped at 50,000 rows and will silently truncate past that. Pull affiliates first, then offers, then conversions, then clicks. The Everflow API returns click IDs as base-32 ULIDs; if you’re mapping to a platform that uses UUIDs, you’ll need a translation table. See our detailed Everflow vs OfferMesh comparison for the field-by-field mapping.

CAKE

CAKE’s UI is older but the export is complete. Go to Admin → Data Export and schedule full-table exports for Affiliates, Offers, Advertisers, Clicks, and Conversions. CAKE’s timestamps are in the account’s configured timezone, not UTC, write that down before you import anywhere. CAKE also stores payout terms in a separate table from the offer table, so you’ll need a join to reconstruct the full offer record. The CAKE vs OfferMesh comparison has the field mapping.

HasOffers / TUNE

HasOffers (now TUNE) has built-in export tools under Reports → Export. The clicks endpoint is heavily paginated, expect to loop for hours on a large account. Custom fields need a separate API call; the UI export won’t include them. TUNE’s API is also rate-limited to 20 requests per second on standard plans, build a retry-with-backoff wrapper before you start the extract, or you’ll lose hours to 429s.

Scaleo

Scaleo supports both CSV and API export. The CSV is fine for small networks, but the API is required if you want per-conversion metadata like sub-IDs, custom parameters, or device fingerprints. Scaleo’s postback template store is only accessible via the API, the CSV omits it entirely. See our Scaleo vs OfferMesh comparison for the parameter map.

Affise

Affise requires the API for a complete extraction. The CSV export from the UI misses postback templates, sub-ID mappings, and fraud rules. Get an API key, budget a full day for the extraction script, and paginate carefully, Affise rate-limits aggressively and doesn’t return standard Retry-After headers, so back off exponentially on 429s. Affise stores conversion status as a numeric enum; keep a legend on hand or your reports will show integers where you expect words.

Setting up the new platform

Create the new account in parallel. Do not touch the old one yet.

Import affiliates first. They’ll receive invites and start familiarizing themselves with the new dashboard before any traffic moves.
Import offers. Match payout, caps, and geo targeting exactly. Every deviation becomes a support ticket during cutover week.
Import advertisers. Recreate every advertiser’s postback template. Do NOT swap the live postback URLs yet.
Generate new tracking links. Publish them to a staging area, do not send them to affiliates yet.
Wire up fraud rules and integrations. Test each one against a known-good conversion before parallel run.
Provision the new tracking domain. If you use a first-party tracking domain (you should), issue and warm the certificate now. Do not wait for cutover day.
Recreate every custom report. Anything your team looks at daily on the old platform needs a mirror on the new one before you cut over.

At this point, the new platform is a full mirror of the old one, but no live traffic is flowing through it. That’s the setup. Take a snapshot of the configuration before you enable any traffic, you will want to compare against it if something drifts during the parallel run.

The parallel run

The parallel run is the single technique that separates a boring migration from a bad one. Every network we’ve seen fail a migration skipped it, shortened it, or ran it without daily reconciliation.

This is the most important section of this post. If you do nothing else right, do this right.

For 14 to 30 days, run BOTH platforms simultaneously. The goal is to prove, with real data, not test transactions, that the new platform produces the same clicks and conversions as the old one, within a tight tolerance.

The mechanics:

Dual-tracking links. Generate a tracking link on both platforms for every offer. Wrap them behind a router (either your own domain or a top-of-funnel redirector) that splits traffic between the two. The router logs both the source click ID and the destination platform, so you can reconcile with a join later.
The traffic split. Start with 90 (old) / 10 (new) for the first three days to catch obvious bugs without risking volume. Move to 50/50 by day 7. Hold at 50/50 through day 30. Do not skip the ramp, 10% traffic surfaces 80% of the bugs at 10% of the risk.
Postback duplication. For the parallel window, advertisers fire postbacks to both platforms. Most platforms accept duplicate postbacks with the same transaction ID and treat the second as a duplicate, verify this on both sides before turning it on in production.
Daily reconciliation. Every morning, pull a click and conversion report from both platforms and diff them. Anything more than a 2% delta is a bug, investigate before proceeding.
Reconcile at the offer level. Aggregate totals can hide a broken offer inside a healthy network. Diff every active offer, every day. A 2% network-wide delta can be 40% off on your biggest single offer.
Test the payout math. At the end of the parallel window, run a full payout calculation on both platforms as if it were the end of the month. If the numbers agree within 1%, you’re ready. If not, you have a systematic mapping error to find.

By the end of the parallel window, you should have two full weeks of reports that agree within 2%. If you don’t, do not cut over. Diagnose the delta first.

Common delta sources during the parallel run:

The two platforms attribute last-click differently on multi-touch journeys.
One platform deduplicates postbacks by transaction ID, the other by click ID.
Bot filtering differs between the two, one platform strips more clicks upstream.
Timezone rollovers happen at different local hours across the two systems.

Each of these can be reconciled, but only if you find it during the parallel window rather than in the first billing cycle after cutover.

The cutover checklist (T-7 to T-0)

The week before cutover looks like this:

T-7 days: All parallel-run deltas are within tolerance. Rollback runbook signed off by the on-call engineer and the head of ops.
T-3 days: Top-20 affiliate notification email goes out. Advertiser engineering contacts pinged for postback swap window.
T-2 days: Long-tail affiliate broadcast queued. New dashboard walkthrough video uploaded to the affiliate portal.
T-1 day: Support team briefed on FAQ. Pre-written responses staged for the most common cutover questions. Rollback dry run.
T-0 (cutover day): Execute the runbook below.

The cutover day

Pick a weekday. Pick your busiest region’s dead hour, usually 3–5am local. Announce the window to your top 20 affiliates 72 hours in advance. Then:

Freeze affiliate onboarding on the old platform. No new accounts, no new offers, no new links from the old side.
Swap advertiser postback URLs to the new platform. One advertiser at a time, in reverse order of volume, smallest first, so you catch bugs on low-stakes traffic.
Update all affiliate-facing tracking links. If you use a shortener or first-party tracking domain, this is a DNS change. If not, it’s a bulk email.
Email affiliates with new links and a short explanation. Include the new dashboard URL, the new link format, and a support contact. One missed payout, even for a good reason, and you’re marked.
Monitor click volume for 24 hours. Compare against the same weekday last week, hour by hour. Any drop above 5% is a red flag.
Reconcile conversions at the end of day 1. New platform totals vs. old platform totals from the parallel window. Should be within 2%.
Reconcile again at the end of day 7. Weekly patterns matter, Sunday traffic looks nothing like Tuesday traffic.

The whole day should be boring. If it isn’t, roll back.

A useful discipline: assign one person to hourly monitoring for the first 24 hours, with a written checklist of what to look at each hour. Click volume, conversion volume, postback error rate, payout accrual rate, dashboard error logs. Fatigue and improvisation are how migrations quietly fail on day one.

Keep the old platform running

Do not cancel the old platform on cutover day. You need it live for:

Chargebacks and clawbacks that reference click IDs generated on the old platform. Merchant chargeback windows are typically 60 to 120 days.
Historical reporting for internal compliance, tax filings, and any audit requests.
Advertiser reconciliation, advertisers often reconcile monthly, and the first post-migration reconciliation will reference old click IDs.
Affiliate dispute resolution, an affiliate who says “you owe me $2,000 from July” needs a defensible answer with real records.
Fraud investigation. If a fraud ring surfaces in the first 30 days after cutover, you’ll want the pre-cutover click history to trace it back.
Legal discovery. If you’re in a regulated vertical, retention of live query access, not just cold-storage exports, may be required.

Cancel the old platform after 90 days minimum. For enterprise-scale networks, 180 days is safer. Downgrade to the lowest read-only tier as soon as your provider allows it, most platforms have a “reporting-only” plan at a fraction of the active-account cost.

Common pitfalls

Mismatched click ID format. Everflow uses base-32 ULIDs; CAKE uses numeric IDs; some platforms URL-encode differently in postbacks. If your click IDs don’t round-trip through the postback exactly, conversions won’t match. Test one live postback per advertiser end-to-end during the parallel run.
Postback signature scheme changes. HMAC-SHA256 vs. HMAC-SHA1 vs. plaintext token vs. IP whitelist. If the new platform uses a different signature, every advertiser’s postback breaks on cutover. Configure both signature schemes during the parallel window so nothing changes on cutover day.
Timezone offsets in conversion timestamps. Old platform in EST, new platform in UTC. Reports won’t line up unless you normalize both to UTC before diffing. Daylight-savings shifts inside the parallel window will produce phantom 1-hour deltas, plan around them.
Missing fields in exports. Custom affiliate fields, sub-IDs, referrer strings, and device fingerprints often don’t come out of standard exports. Ask specifically, and diff a sample export against the UI record to confirm nothing is silently dropped.
Hardcoded old-platform URLs in advertiser CRM. Marketing automation platforms, CRMs, and email systems sometimes have your postback URL hardcoded in a template you don’t own. Ask every advertiser to grep their configs during the parallel window, not after cutover.
Affiliate confusion around new dashboard URL. Even with a clear announcement, half your affiliates will email support asking where their dashboard went. Prep the support team with a canned response, a video walkthrough, and a redirect from the old dashboard URL.
Cookie consent domain-scoping breaking cross-device. If you moved from track.oldnetwork.com to track.newnetwork.com, consent cookies don’t transfer. GDPR and CCPA consent flows may re-fire, dropping repeat-visitor attribution.
Rate limiting on postbacks. Some new platforms rate-limit incoming postbacks more aggressively than the old one. Cutover-day traffic spike can cause silent drops, pre-warm the rate limiter with the new platform’s support team before the switch.
Fraud rule regression. Fraud rules configured over months on the old platform rarely map one-to-one. Expect to spend the first two weeks post-cutover tuning velocity thresholds and IP blocklists back to their old accuracy.

Rollback plan

Every cutover needs a rollback plan documented in writing before the cutover starts. If you can’t hand a one-page rollback runbook to someone who wasn’t in the migration meetings and have them execute it, you don’t have a rollback plan, you have wishful thinking.

Rehearse it. Do not improvise a rollback at 4am while conversions are dropping.

The 48-hour rollback consists of five steps, in order:

DNS-swap the old tracking domain back. If you used a first-party domain, this is a single DNS change. If not, you need to re-issue the old tracking links to affiliates immediately.
Restore old postback URLs. Swap every advertiser’s postback back to the old platform. Have the change script pre-written.
Notify affiliates with fallback links. Same email list, same template. Say clearly: we’re rolling back, no revenue is lost, here’s the temporary link.
Communicate transparently. A rollback done well is a story about a professional team. A rollback done poorly is a story about a broken network. Silence guarantees the second one.
Post-mortem within 72 hours. Diagnose the failure, fix it, and reschedule the cutover for at least 30 days later.

The rollback should be a single-command script, not a runbook. If it takes more than 30 minutes to execute, you didn’t practice it.

Post-migration verification

The first 30 days are where migrations quietly fail. Verification cadence:

Days 1–7: daily click reconciliation. Diff yesterday’s clicks between old and new platforms, the parallel data still flowing gives you a golden reference. Max acceptable delta: 2%.
Days 1–30: weekly conversion reconciliation. Full conversion count, aggregate revenue, per-offer breakdown. Max acceptable delta: 1%.
Days 1–90: monthly payout reconciliation. The single number that matters to affiliates. If payouts differ from what the old platform would have produced, find out why before you send them.
Days 30–90: quarterly compliance check. Confirm that historical data pulls, tax reports, and any regulator-facing exports still produce identical numbers between old and new. Some auditors will ask for pre-cutover data on a schedule that runs past the cancellation window.

Any delta above threshold gets a ticket, a root cause, and a fix. No “it’s probably just a rounding issue.” Rounding issues don’t stack for three weeks.

If you’re building this reconciliation from scratch, plan on a small internal tool. A shared spreadsheet does not scale past the third week. Automate the diff, alert on threshold breaches, and log every reconciliation decision.

Migration cost

Migrations are not free. The direct cost is the smaller half, the bigger half is the opportunity cost of a team focused on migration instead of growth for 30 to 60 days.

Budget realistically:

Team time. A typical migration is 40–80 hours of engineering and ops time spread over 30 days. Founder-led networks tend to underestimate this by half. Add another 20 hours of support time for the affiliate-facing communication burden during cutover week.
Traffic loss during cutover. A 1–3% dip is normal and recoverable. A 5%+ dip means something is broken, investigate immediately, don’t wait for the day 7 reconciliation.
Platform overlap cost. Both subscriptions run for 30 to 60 days minimum, 90 days if you want to be safe. Budget the double. On enterprise platforms this can be a five-figure line item.
Affiliate goodwill cost. If the migration goes badly, expect a 5–15% affiliate churn over the following quarter. If it goes well, expect zero. Top affiliates leave first, the cost is asymmetric.
One-time engineering cost. Custom export scripts, mapping scripts, and reconciliation tooling. For a mid-sized network, plan on 40 hours of engineering just for the tooling that doesn’t ship with either platform.
Optional: professional migration help. For networks over $500K/mo GMV, the cost of a professional migration is small relative to the risk of doing it yourself.

FAQ

How long does a full migration take?

Six to twelve weeks end-to-end. Two weeks of audit and setup, two to four weeks of parallel run, one day of cutover, 30 days of verification, 60 more days of parallel operation on the old platform. Larger networks or regulated verticals should assume the upper end.

Will I lose historical reports?

No, if you export before cutover. Keep the exports (raw CSV plus API dumps) in cold storage for at least seven years. The old platform’s own reports remain accessible as long as you keep the subscription live.

Do I need to notify all my affiliates?

Yes. Top-tier affiliates get 72 hours’ advance notice by direct email. The long tail gets a broadcast the morning of cutover with the new dashboard URL and new link format. Silent migrations are how you lose your top-10 affiliates.

What if my advertiser’s CRM has hardcoded old links?

Ask advertisers to grep their configs during the parallel window, not after cutover. If you find hardcoded URLs, negotiate a change window with each advertiser’s engineering team. Some CRMs allow a bulk find-and-replace; others require a manual template edit per record.

Can I migrate without downtime?

Yes, that’s the entire point of the parallel run. If the parallel-run window is honored, the cutover is a DNS change and a bulk email, not a maintenance window. Downtime is a symptom of skipped steps, not an inherent property of migration.

Do I keep the old platform forever?

No. Cancel after 90 days minimum, 180 days if you’re at enterprise scale or in a regulated vertical. After that, exports live in cold storage.

What if the new platform’s postback signature scheme is different?

Configure both signatures during the parallel run. Every advertiser fires postbacks to both platforms during the parallel window, so you’ll see immediately if the new signature verification fails. If you can’t reconcile the signature scheme, ask the new platform whether they can add compatibility with your existing scheme, most will, for a paying customer.

How do I handle chargebacks that reference old click IDs?

The old platform stays live for exactly this reason. When a chargeback references an old click ID, look it up on the old platform, credit or debit the affiliate on the new platform, and log the cross-reference. After 90 days, chargebacks referencing pre-cutover clicks are effectively closed.

What tolerance is acceptable for click and conversion deltas?

2% for clicks, 1% for conversions. Anything above those thresholds gets a ticket and a root cause, not a shrug. Rounding does not stack for three weeks.

Should I migrate mid-month or month-end?

Mid-month. Month-end concentrates payouts, invoices, and advertiser reconciliation into the same window as your migration. Give yourself space.

Closing

Migrations are boring when they’re done right, and every step in this checklist exists because we watched something break the last time it was skipped. Audit before you set up. Set up before you parallel-run. Parallel-run before you cut over. Verify before you cancel. Skip a step and you’re improvising in production at 4am.

If you’re considering a move off Everflow, CAKE, HasOffers, Scaleo, or Affise, our affiliate network migration tools automate the export, mapping, and parallel-run reconciliation, and our team has run this playbook end-to-end more times than we’d like to admit.

If you’re specifically comparing options after Everflow, our companion post on Everflow alternatives in 2026 walks through the platforms worth evaluating. Or start with the migration landing page and see what a parallel-run import from your current platform actually looks like.

Ready to move? Start a 14-day trial at offermesh.app, parallel-run import is included on every plan.