Here’s the blunt truth, right up front, for the exec who only reads the first paragraph:
A casino affiliate migration is successful only if the same player, triggering the same event, produces the same payout—bit-for-bit—before, during, and after the cutover.
If you can’t prove that down to the individual player level, you didn’t migrate. You rolled the dice and hoped for the best.
Everything below exists to enforce that invariant. We, the team behind Scaleo, have migrated casino programs with tens of thousands of active affiliates, millions of historic clicks, hybrid CPA+RevShare deals, soft-locked players, and legacy macros nobody remembered existed.
The pattern is always the same: migrations fail not because of software bugs, but because teams catastrophically underestimate how much institutional memory is embedded in tracking links, macro expansions, and “temporary” commission exceptions that quietly became permanent three years ago.
This runbook is opinionated. Some popular industry advice is flat wrong, and we’ll dismantle it as we go.
What Actually Defines an Affiliate Migration?
An affiliate migration is the controlled transfer of tracking logic, attribution rules, financial contracts, and reporting pipelines from one system to another—without breaking player identity continuity or commission economics.
Zero downtime does not mean “no outages.”
It means no attribution ambiguity.
If a player clicks Affiliate A’s link on the old system at 14:32 and registers at 14:38 after you’ve cut over to the new system, that conversion must still attribute to Affiliate A with the correct commission rate, the correct attribution window, and the correct player lifetime lock. If it doesn’t, you’ve created a dispute that will cost you more in affiliate relationship damage than the migration itself.
The goal isn’t uptime. The goal is perfect attribution continuity across system boundaries.
The 2026 Reality That Changes Everything
Casino migrations are harder in 2026 for one structural reason: attribution windows are collapsing while audit expectations are expanding.
Operators now reconcile:
- Real-time S2S postbacks from gaming platforms.
- Player-level event streams across registration, KYC, deposits, wagering.
- BI pipelines feeding finance teams and compliance departments.
- Affiliate disputes backed by raw click logs and event chains, not screenshots.
Safari’s ITP restrictions have forced most operators to server-side tracking. That means your migration needs to preserve not just cookie-based attribution, but server-side session persistence, Click ID mapping, and postback webhook configurations that weren’t even documented when they were originally set up.
If your migration plan doesn’t assume parallel tracking and forensic-level QA, you’re already behind.
The Popular (Wrong) Migration Approach
Here’s the advice we see operators get from consultants who’ve never actually run a casino affiliate program:
“Just freeze affiliate traffic for a weekend, switch all the tracking links, import your data, and reconcile discrepancies later.”
No. Absolutely not.
Freezing traffic creates:
- Lost lifetime value from organic player re-routing (they’ll find another casino)
- Affiliate distrust and immediate Telegram drama
- Irreconcilable gaps in event attribution that persist for months
- Finance teams manually adjusting payouts based on “gut feel” instead of data
The correct approach is controlled parallelism, not downtime.
You run both systems simultaneously, prove mathematical equivalence at the player level, then cut traffic gradually by cohort while maintaining rollback capability. This takes longer. It’s more work. It also actually works.
Migration Framework (Before We Get Tactical)
The high-level flow looks like this:
- Inventory everything that moves money or touches player identity
- Run both systems in parallel with deterministic parity tests
- Prove equivalence at player, event, and payout levels
- Cut traffic gradually by cohort, not atomically
- Keep rollback capability alive longer than you think you need
Each of these phases has specific failure modes we’ll cover. But first, let’s get granular on the week-by-week execution.
Week-by-Week Migration Timeline
Week 0: Governance Lock (Before You Touch Anything Technical)
Before writing a single line of migration code or configuring a new platform, you need to lock down decision rights across your organization.
Here’s who owns what:
| Role | Ownership | Non-Negotiable Responsibility |
|---|---|---|
| Ops | Affiliate contracts & relationships | Defines what “correct payout” means |
| Tech | Tracking systems & API integrations | Guarantees event delivery and data integrity |
| BI/Data | Attribution logic & reporting parity | Proves numbers match across systems |
| Finance | Reconciliation & payouts | Signs off that money flows correctly |
| Legal/Compliance | Player data handling & GDPR | Approves data migration and retention |
If Ops and BI don’t agree on what “correct” means, stop here. You cannot migrate successfully when different teams are optimizing for different definitions of success.
Deliverable for Week 0: A signed document stating: “System X is the source of truth for player Y’s attribution to affiliate Z, and payout amount is calculated using logic ABC.” Every stakeholder signs it. This becomes your arbitration document when disputes arise.
Week 1: Full Inventory (No Exceptions, No Shortcuts)
This is where migrations silently fail before they even begin.
You need to inventory every construct that affects attribution or payouts:
| Asset Type | What We Inventory | Why It Breaks During Migration |
|---|---|---|
| Affiliate Links | Base URLs, tracking parameters, redirect chains | Hidden hard-coded affiliate IDs that don’t map to new system |
| SubIDs | Formats, max character length, encoding rules | New system truncates at 50 chars, old allowed 100 |
| Click IDs | Uniqueness guarantees, collision handling | Double-counting when Click ID formats differ |
| Postbacks | URLs, authentication methods, retry logic | New system times out faster, drops events |
| Macros | Custom placeholders, deprecated variables | {player_currency} doesn’t exist in new platform |
| Payout Rules | CPA/RevShare hybrids, tier structures | RevShare calculation rounds differently |
| Geo Rules | Country-specific overrides, blocked regions | Silent eligibility loss when defaults change |
| Player Locks | Lifetime attribution logic, soft locks | Player gets re-attributed to wrong affiliate |
Real example that cost an operator €47,000:
Their old system allowed SubIDs up to 255 characters. Affiliates used this for detailed UTM tracking: source|campaign|adset|creative|landing_page_variant|geo|device. New system capped SubIDs at 100 characters. Migration script silently truncated everything after character 100.
Affiliates’ tracking broke. They couldn’t optimize by placement anymore. Three top affiliates paused traffic. Took six weeks to fix and rebuild trust.
Deliverable for Week 1: A spreadsheet listing every affiliate with their unique tracking quirks, every custom macro in use, every non-standard payout rule. If it affects who gets paid, it’s in the inventory.
Week 2: Mapping & Normalization
Every legacy construct must map cleanly to the new system. No exceptions, no “we’ll handle that manually.”
| Legacy Concept | Migration Decision | Technical Mechanism |
|---|---|---|
| Custom SubID chains | Preserve exact structure | Regex-safe parsing with validation |
| Deprecated macros | Alias to new equivalents or document removal | Macro translation layer |
| RevShare calculation buckets | Normalize event definitions | Event-level tagging and mapping rules |
| Soft player locks | Enforce deterministic behavior | Player ID binding with lock timestamp |
This is where Scaleo’s architecture matters.
Unlike legacy platforms that require custom code for every edge case, Scaleo’s macro system and event normalization engine let you define translation rules declaratively. When the old system fires a first_deposit_confirmed event and the new system expects ftd, you configure the mapping once rather than modifying code.
Common mapping failures:
RevShare calculation differences: Old system: (wagers - wins - bonuses) * commission_rate New system: (wagers - wins) * commission_rate (doesn’t deduct bonuses by default)
If you don’t catch this in Week 2, every RevShare affiliate gets overpaid or underpaid starting from cutover. Finance catches it three months later. You owe back-payments or clawbacks. Disaster.
Deliverable for Week 2: A mapping document showing: Old System Construct → New System Equivalent → Validation Test. Every row needs a test case proving the mapping works.
Week 3: Parallel Tracking (Shadow Mode)
This is the most critical phase of the entire migration.
Traffic continues flowing through the old system as your production source of truth. Simultaneously, the new system receives mirrored events in shadow mode—it tracks everything but doesn’t affect live attribution or payouts yet.
| Signal | Old System | New System |
|---|---|---|
| Click Timestamp | Source of truth | Compared for drift |
| Player ID | Canonical identifier | Must match exactly |
| Event Type | Reference definition | Must map correctly |
| Payout Amount | Reference calculation | Must match within €0.01 |
We don’t “eyeball” this comparison. Your BI team runs row-level diffs comparing every click, every conversion, every payout calculation between systems.
Parallel tracking implementation:
Your gaming platform fires postbacks to both systems:
POST old-system.com/postback?click_id=ABC&event=ftd&amount=200
POST new-system.scaleo.io/postback?click_id=ABC&event=ftd&amount=200
Both systems process the same event. Your BI pipeline pulls data from both, joins on player_id + timestamp, and flags any discrepancies.
What you’re looking for:
- Click IDs that exist in one system but not the other
- Events that trigger different payout amounts
- Attribution going to different affiliates
- Timing drift (old system processes instantly, new system has 2-second delay)
If you’re not running parallel tracking, you’re guessing. You’ll discover discrepancies after cutover when affiliates start complaining and you have no diagnostic data.
Deliverable for Week 3: Daily reconciliation reports showing: Events processed by both systems, delta count, delta amount, root cause for every discrepancy >€1.
Week 4: QA Phase – “Same Player, Same Event, Same Payout”
This phrase becomes your mantra. Write it on the whiteboard. Put it in Slack. Make it your religion.
The validation is forensic:
| QA Dimension | Validation Method | Failure Symptom |
|---|---|---|
| Identity | Player ID hash comparison across systems | Split LTV (player shows up twice) |
| Timing | Event latency delta measurement | Missed CPA (event arrived after attribution window closed) |
| Attribution | Click→event chain verification | Wrong affiliate credited |
| Finance | Payout math verification at player level | Rounding drift, calculation differences |
One failed dimension blocks go-live. No exceptions. No “we’ll fix it later.”
Test cases we actually run:
- Click replay test: Take 10,000 historical clicks from the old system, replay them through the new system’s ingestion API, verify identical attribution outcomes.
- Event replay test: Generate synthetic FTD events with known player IDs, fire them at both systems, compare payout calculations.
- Macro fuzzing: Send randomized SubID values with special characters (
test|value¶m=123), verify no truncation or encoding errors. - Latency stress test: Send burst traffic (1,000 clicks/second for 60 seconds), verify no dropped events, no attribution failures.
- Reconciliation proof: Pull last month’s complete payout data from old system, reprocess through new system’s calculation engine, prove identical results.
If your QA stops at “the dashboards look similar,” you’re in trouble. We’ve seen operators lose €200K+ in disputes because they didn’t validate at player level.
Deliverable for Week 4: QA sign-off document stating: “We have validated equivalence at player, event, and payout levels. Test results attached. No blocking issues remain.”
Week 5: Gradual Cutover (Cohort-Based Traffic Migration)
You do not flip a switch and move 100% of traffic atomically. You cut by cohort, observe, validate, then proceed.
| Cohort | Traffic % | Observation Window | Rollback Trigger |
|---|---|---|---|
| Internal test traffic | 5% | 48 hours | Any attribution discrepancy |
| Tier-1 affiliates (pre-briefed) | 20% | 72 hours | Affiliate complaint or data mismatch >2% |
| Long-tail affiliates | 50% | 72 hours | Finance reconciliation failure |
| Full migration | 100% | Continuous monitoring | Material payout variance |
How cutover works technically:
You control traffic via redirect logic. When a click comes in for Affiliate ID 12345, your routing layer checks: “Is this affiliate in the cutover cohort?” If yes, route to new system. If no, route to old system.
if affiliate_id in cutover_cohort:
redirect_to("new-system.scaleo.io")
else:
redirect_to("old-system.legacy.com")
Why gradual matters:
When you cut over your top 5 affiliates (20% of volume) and something breaks, you’ve contained the blast radius. You can rollback those 5 affiliates while investigating. If you’d cut over all 400 affiliates, you’d have 400 simultaneous disputes.
Deliverable for Week 5: Cutover schedule with specific affiliate IDs per cohort, monitoring dashboards tracking both systems during transition, documented rollback procedure.
Week 6: Decommissioning (But Keep History Alive)
The old system gets decommissioned, but not deleted.
What stays accessible:
- Old system remains in read-only mode for reporting
- Historical data exports remain available
- Postback endpoints stay live but disabled (for forensic analysis)
What gets turned off:
- Click ingestion (no new clicks)
- Live postback processing (new events go to new system only)
- Affiliate-facing dashboards (redirect to new system)
Why this matters:
Three months after migration, an affiliate disputes a payout from two months ago. They claim Player ID 847392 was theirs, you credited someone else. Without access to old system logs showing the complete click chain, you’re adjudicating based on memory.
Keep history. Storage is cheap. Disputes are expensive.
Deliverable for Week 6: Archive plan documenting: What data is retained, where it’s stored, who has access, for how long (minimum 2 years for compliance).
QA Checklist (What We Actually Test in Production Migrations)
This isn’t theoretical. This is the literal checklist we use when migrating casino operators to Scaleo.
| Test | Tooling | Expected Outcome |
|---|---|---|
| Click replay | Historical log re-ingestion via API | 100% identical attribution to original |
| Event replay | Synthetic event generator | Payout calculations match within €0.01 |
| Macro fuzzing | Randomized parameter injection | No truncation, no encoding errors |
| Latency stress | Load testing tool (1K req/sec) | Zero dropped events, sub-200ms p99 latency |
| BI reconciliation | SQL diffs on production data | Zero variance in total payouts |
| Affiliate dashboard parity | Screenshot comparison | All metrics match old system |
| Postback validation | Webhook log analysis | All events received, no duplicates |
| Currency conversion | Multi-currency test transactions | Exchange rates match, no rounding errors |
| Geo rule verification | VPN testing from blocked countries | Correct rejection/acceptance behavior |
| Player lock testing | Multi-click scenarios | Lifetime attribution preserved |
If your QA checklist has fewer than 8 items, you’re missing failure modes.
Rollback Strategy (Because You Will Need One)
Rollback is not failure. Not having rollback is failure.
The ability to revert to the old system in under 10 minutes is your insurance policy. Here’s how it works:
| Layer | Rollback Action | Trigger Condition | Execution Time |
|---|---|---|---|
| Traffic routing | DNS/redirect switch back to old system | Attribution drift >5% | <5 minutes |
| Postback processing | Re-enable old system webhooks | Event loss detected | <2 minutes |
| Payout calculations | Freeze new system, revert to old | Finance reconciliation failure | <10 minutes |
| Affiliate dashboards | Revert dashboard URLs | BI data inconsistency | <5 minutes |
Rollback must be executable in minutes, not hours.
How we implement rollback:
Traffic routing is controlled by a feature flag:
if feature_flag("new_affiliate_system") == true:
route_to_new_system()
else:
route_to_old_system()
You flip the flag to false. Traffic immediately routes back. Old system never stopped running (it’s been in standby), so it picks up where it left off.
When to trigger rollback:
- Attribution accuracy drops below 95% (vs parallel tracking baseline)
- More than 3 affiliate disputes within 24 hours
- The finance team cannot reconcile payouts within 2% variance
- Critical bug discovered that affects payout calculations
- Gaming platform postbacks failing at >5% rate
Don’t wait to see if it fixes itself. Rollback, diagnose, fix, re-attempt cutover.
Top 10 Migration Failure Modes (We’ve Seen Every One)
We’ve migrated enough casino programs to see the same failures repeatedly. Here’s what actually breaks:
| # | Failure Mode | Why It Happens | Prevention |
|---|---|---|---|
| 1 | SubID truncation | New system has shorter character limits than old | Inventory max lengths in Week 1, validate in Week 4 |
| 2 | Macro mis-mapping | Legacy macros ({custom_id}) don’t exist in new system | Map every macro in Week 2, test with fuzzing |
| 3 | Double CPA fires | Event deduplication rules differ between systems | Implement identical dedupe logic, validate in parallel tracking |
| 4 | RevShare calculation drift | Rounding differences (old: 2 decimals, new: 4 decimals) | Document exact calculation, compare at player level |
| 5 | Player re-attribution | Cookie-based old system vs S2S new system creates conflicts | Use Click ID as canonical identifier, not cookies |
| 6 | Geo rule loss | Default country rules override specific exceptions | Export all geo overrides, import with validation |
| 7 | Delayed postbacks | New system has stricter timeout (5s vs old 30s) | Test latency under load, adjust timeout configs |
| 8 | BI aggregation mismatch | Old system aggregates hourly, new aggregates daily | Align aggregation grain, test reconciliation |
| 9 | Affiliate panic | Poor communication creates trust issues | Pre-brief top affiliates, provide migration FAQ |
| 10 | No rollback plan | Overconfidence leads to “we’ll fix forward” mentality | Document rollback before cutover, test the switch |
Real example: Failure Mode #5 (Player re-attribution)
Operator migrated from cookie-based tracking to Scaleo’s S2S tracking. Old system used first-party cookies to track players. New system used Click IDs in postbacks.
Player clicked Affiliate A’s link (old system set cookie). Before converting, player clicked Affiliate B’s link after cutover (new system logged Click ID). Player converted via postback with Click ID from Affiliate B.
Old system’s cookie said Affiliate A. New system’s Click ID said Affiliate B. Finance paid based on new system. Affiliate A disputed with cookie evidence.
Fix: During parallel tracking, migrate cookie data to the Click ID mapping table. When postback arrives, check both the cookie and the Click ID, apply documented attribution rules (first-touch vs last-touch), resolve consistently.
Cost of not catching this in parallel tracking: €23,000 in disputed commissions and one lost top-tier affiliate.
What Documentation Never Tells You (The Emotional Dimension)
Affiliate migrations fail emotionally before they fail technically.
Your affiliates don’t care that you’re upgrading to a better platform with nicer dashboards and more features. They care about trust continuity. They’ve been sending you traffic for 18 months, building up lifetime player value, and relying on your commission checks.
If they suspect—even incorrectly—that numbers changed during migration, you’ll spend three months in Telegram groups and email threads defending your integrity instead of growing your program.
What actually works:
Pre-brief your top 20 affiliates before migration. Tell them:
- Exactly when cutover happens
- What will change (dashboard URL, login method)
- What will NOT change (commission rates, attribution windows, player locks)
- How they can verify their data migrated correctly
- Direct contact for migration support questions
Transparency beats perfection. If you discover a discrepancy, tell affected affiliates immediately and explain how you’re fixing it. Don’t wait for them to notice and lose trust.
How Scaleo Handles Migrations (The Technical Advantage)
We built Scaleo after watching too many casino migrations fail due to inflexible legacy platforms that couldn’t handle the nuances of iGaming attribution.
What makes Scaleo migrations cleaner:
Macro translation layer: Instead of hard-coding event mappings, you configure them. Old system sends first_deposit_approved? Map it to ftd in Scaleo without code changes.
Event normalization engine: Different gaming platforms use different schemas. Scaleo normalizes at ingestion, so your attribution logic stays consistent regardless of source.
Parallel tracking mode: Built-in capability to ingest events from both old and new sources, compare them, and flag discrepancies. No custom scripting required.
Player-level audit trail: Every click, every event, every payout decision is logged with immutable timestamps. When disputes happen, you have forensic evidence.
Configurable deduplication: Define exactly how duplicate events are handled (per player? per Click ID? per time window?). Make it deterministic so old and new systems behave identically.
Real-world migration results:
A casino operator migrated 8,400 active affiliates to Scaleo using the runbook above. Total discrepancies during parallel tracking: 0.07% of events (mostly timing-related, resolved by adjusting event windows). Zero affiliate disputes post-cutover. Finance reconciliation variance: €340 out of €1.2M monthly payout (0.03%).
That’s what proper migration execution looks like.
The Uncomfortable Question Worth Asking
Here’s what separates operators who migrate successfully from those who don’t:
If you migrated tomorrow, could you prove—down to a single player—that nothing changed except the software?
Can you show Player ID 472849’s complete lifecycle: which affiliate’s Click ID they came from, which events fired when, what commission was calculated, and prove that all of those would be identical in the new system?
If the answer is “probably” or “we think so,” you’re not ready.
The successful migrations we’ve executed all share one trait: obsessive focus on provable equivalence. Not estimated. Not close enough. Proven.
That’s the difference between a migration that works and a migration that costs you six figures in disputes and lost affiliates.
Ready to migrate your casino affiliate program without the chaos? Scaleo’s migration team has executed zero-dispute cutover for casino operators processing €50M+ in annual affiliate payouts. We handle parallel tracking, parity validation, and phased rollout while your team focuses on running the business. Schedule a migration consultation to see how we prove “same player, same event, same payout” at the forensic level.
