At some point in the history of almost every iGaming operator who built their own affiliate tracking system, there was a moment where it made complete sense. You had a specific NGR formula your off-the-shelf options could not handle. Your casino backend had an unusual postback structure that no third-party platform supported without expensive custom work. Or the monthly licensing fees for commercial affiliate software looked substantial compared to the cost of a few sprints of engineering time. So you built. And it worked.
⚡ BOTTOM LINE
Custom-built affiliate platforms are the right choice at a specific moment in an operator’s growth — when no commercial platform handles the required features, and engineering capacity exists to build and maintain bespoke infrastructure. Beyond that moment, they become a maintenance liability that occupies engineering resources, generates affiliate relationship friction, and falls progressively further behind commercial platforms that invest continuous development budgets in the same problem. Switching to a SaaS platform recovers those engineering hours, delivers features that would take months to build internally, and — when the migration is handled correctly — is operationally transparent to your affiliate partners. The migration itself is the part most operators fear unnecessarily. Done correctly, it takes weeks, not months, and the affiliate experience typically improves rather than degrades.
Then the engineer who built it left the company. Or the business grew and the system started behaving differently under load. Or a new compliance requirement arrived that meant adding a feature your internal platform was not designed to accommodate, and the team estimated eight weeks to build it. Or your affiliates started complaining that the portal was slow and the commission statements were hard to read. Or all of these things happened in the same quarter.
The decision to switch from a custom-built affiliate platform to a SaaS solution is almost never about the platform being objectively broken. It is about the total cost of keeping it running — in engineering hours, in opportunity cost, in affiliate relationship friction, in features you are building from scratch that a commercial platform already offers and improves continuously. That cost compounds quietly until something forces the calculation into the open.
Why Operators Build Custom Affiliate Platforms
The decision to build a custom affiliate tracking platform rather than licensing a commercial solution is rational under specific conditions. Understanding those conditions is important context for the switching decision — because the arguments that justified building are often still present when operators are evaluating whether to switch, and they need to be addressed directly rather than dismissed.
The feature gap argument. In the early years of regulated iGaming affiliate marketing, commercial platforms were genuinely unable to handle the complexity that serious operators required. NGR calculations that involved per-game-provider royalty deductions at different rates. NCO policies that varied by affiliate tier and reset logic. Multi-brand affiliate management that required separate tracking domains but unified reporting. These requirements were either not supported by commercial platforms or supported only in ways that required significant workarounds. For operators with engineering capacity, building a custom system that exactly matched their commission model was faster than configuring workarounds in a commercial platform that was designed for simpler use cases.
The cost argument. Commercial affiliate platform licensing is a recurring cost. A custom-built system, once developed, has only marginal maintenance costs — or so the calculation appeared at build time. The engineering sprint to build a basic affiliate tracking system with a click ID mechanism, a postback endpoint, and a commission calculation script could be completed in a few weeks. Compared to a SaaS license at several hundred to several thousand euros per month, building looked like the better long-term financial decision.
The control argument. A custom platform gives the operator full control over the data model, the tracking schema, the commission calculation logic, and the affiliate-facing reporting. There are no vendor limitations, no support tickets for features that do not exist yet, and no risk that a commercial platform’s pricing or terms change in ways that affect the business. The affiliate data lives on the operator’s own infrastructure under the operator’s own terms.
All three arguments have merit. None of them are timeless — they apply at the moment of the build decision and erode progressively as the business scales, the platform ages, and the gap between internal development capacity and what commercial platforms deliver continues to widen.
Where Custom Platforms Break Down
Custom affiliate platforms do not fail suddenly. They degrade gradually, through a series of symptoms that individually seem manageable until they are viewed together as a maintenance pattern.
The Knowledge Concentration Problem
A custom platform built by one or two engineers exists primarily in their heads. The commission calculation logic, the postback retry behavior, the specific edge cases that were handled by specific code paths — all of this institutional knowledge lives with the people who wrote it. When those people leave the company, which in iGaming’s high-turnover tech environment happens regularly, the platform becomes a system that nobody fully understands operating in production without a complete specification.
The practical consequence: every maintenance request, every bug investigation, and every feature addition takes longer than it should because the engineer addressing it is working from incomplete context. “The commission calculation does something weird for hybrid affiliates with NCO balances over a certain threshold, but we’re not sure exactly when it triggers” is a verbatim description of the kind of issue that appears in operator engineering backlogs when the original platform author is no longer available. The system is not broken — it is just undocumented, which becomes indistinguishable from broken when the calculation produces a number that an affiliate disputes and nobody can trace the logic that produced it.
The Feature Parity Gap
Commercial affiliate platforms have dedicated engineering teams building new features continuously. A platform like Scaleo ships improvements to its fraud detection engine, its mobile affiliate portal, its postback retry logic, and its commission reporting on an ongoing development cycle. A custom-built platform ships features when an operator’s engineering team has capacity — which, in a growing iGaming business, is almost never. The competitor who moved to a SaaS platform two years ago now has behavioral anti-fraud scoring, deferred deep link attribution for mobile, real-time WebSocket commission notifications, and a sub-second affiliate portal load time. The operator who kept their custom platform has whatever features were built in the original sprints, plus the three features that were prioritized over the last eighteen months of sparse engineering attention.
The gap starts small and accelerates. Commercial platforms invest their development capacity in affiliate platform features because that is their entire product. Operators invest their development capacity in casino product, game integration, payment processing, and customer experience — the affiliate platform is one system among many competing for limited engineering time. After three years, the feature gap between a maintained commercial platform and a deprioritized custom one is substantial.
The Scale Failure Pattern
Custom affiliate tracking systems are typically built for the traffic volume that exists at build time, with some headroom for growth. When traffic exceeds that headroom — during a major sports event, a jackpot campaign, or a period of rapid affiliate partner growth — systems that were not engineered for high-volume asynchronous postback processing experience predictable failures: queue saturation, duplicate commission events, postback timeouts that generate affiliate disputes, and database lock contention that slows commission calculation for the entire program during peak windows.
Fixing these failures requires architectural changes that are significantly more complex than the original build. Decoupling postback receipt from postback processing into an asynchronous queue architecture, implementing deduplication at the player-ID level, adding exponential backoff retry logic, and distributing the receiving infrastructure geographically are the changes a commercial platform has already made. Making them in a custom platform means rewriting the most critical parts of the tracking infrastructure while it is running in production — a project that requires careful engineering capacity and a parallel-run period that keeps both the old and new systems operational simultaneously.
⚠️ The hidden cost calculation most operators skip: When evaluating whether to switch from custom to SaaS, the comparison is almost always framed as “current SaaS license cost vs current maintenance cost.” The correct comparison is total engineering cost of the custom platform over the next 24 months — including maintenance, bug fixes, compliance requirement additions, the scale architecture upgrade if traffic grows, and the feature backlog that is currently deprioritized — versus the SaaS license cost over the same period. When operators run that full comparison honestly, the SaaS option almost always wins on cost alone, before accounting for the features they would gain and the affiliate relationship improvement from a better portal experience.
The Real Cost Comparison: Custom vs SaaS Over 24 Months
| Cost Category | Custom-Built Platform (24 months) | SaaS Platform — Scaleo (24 months) |
|---|---|---|
| Platform license / hosting | €800–€2,400 (server costs) | €8,400–€28,800 (SaaS license, scale-dependent) |
| Engineering maintenance (bug fixes, uptime) | €18,000–€48,000 (estimated 2–5 hours/week at senior dev rate) | €0 (vendor responsibility) |
| Compliance requirement additions | €6,000–€24,000 per new requirement (GDPR updates, regulatory reporting, new market requirements) | €0 (vendor ships compliance updates) |
| Scale architecture upgrade | €20,000–€60,000 if asynchronous queue rewrite required | €0 (infrastructure scales with SaaS) |
| Feature development (fraud, mobile portal, reporting) | €30,000–€90,000 for equivalent feature set | €0 (included in license; continuous development) |
| Affiliate dispute resolution overhead | High — manual audit against undocumented calculation logic | Low — itemized commission statements reduce disputes; audit log in platform |
| Migration cost (one-time) | N/A | €8,000–€20,000 (data mapping, postback reconfiguration, affiliate communication) |
| 24-month total (excluding migration) | €74,800–€224,400 | €8,400–€28,800 |
Cost ranges are estimates based on Scaleo migration data and operator-reported engineering time. Engineering rates assumed at €80–€120/hour for senior iGaming backend developer. Actual costs vary by platform complexity and operator size.
The platform license cost comparison, viewed in isolation, makes custom appear significantly cheaper. The total cost comparison — including the engineering time that the custom platform consumes — reverses the picture. For most operators, the custom platform’s 24-month total cost exceeds the SaaS alternative by a factor of 3–8x, with the gap concentrated in engineering maintenance and the feature development backlog that the SaaS platform ships as standard.
What Makes Custom-to-SaaS Migration Different
The migration challenges for operators moving from a custom-built platform differ in important ways from those facing operators migrating from one commercial platform to another (Affilka to Scaleo, for example). Commercial platforms have standardized export formats, documented data schemas, and in many cases pre-built migration templates. Custom platforms have whatever data structure the original engineering team decided on, which may be deeply idiosyncratic.
Three challenges specific to custom-to-SaaS migration:
Data Schema Mapping
The historical affiliate data in a custom platform — commission history, player attribution records, NCO balances, click logs — needs to be exported and mapped to the target platform’s schema. The complexity of this mapping depends entirely on how the custom platform stores data. A well-structured relational database with clean foreign key relationships and documented field definitions is a manageable export and mapping exercise. A system where the NGR formula lives in application code rather than a database field, where NCO balances are recalculated from raw transaction history on every report run rather than stored as a running balance, or where affiliate account records exist in multiple tables without clear normalization requires schema reconstruction before migration can begin.
The practical first step before any migration planning: conduct a data audit. Export a sample affiliate’s complete commission history from the custom system and verify that you can reconstruct the exact figures from the underlying data fields. If you cannot — if the calculation lives in application code that nobody currently fully understands — that is the most important thing to resolve before migration begins, because Scaleo’s migration team will need a clear, documented NGR formula to replicate in the new platform.
Affiliate Tracking Link Architecture
Custom affiliate platforms use custom tracking domains and custom click ID formats. Your affiliates have tracking links embedded in their content — on their websites, in email campaigns, in social media bios — that point to your custom tracking infrastructure. When you migrate to Scaleo, those links need to either redirect to Scaleo’s tracking endpoints or be replaced with new Scaleo-generated links.
The redirect option is the lower-friction path for affiliates: your old tracking domain serves a permanent redirect (301) to the equivalent Scaleo tracking URL, with the affiliate’s ID passed as a parameter. Affiliates do not need to update any of their existing links. The redirect adds one network hop to the click path, which is operationally negligible. The redirect infrastructure on your old tracking domain needs to remain active for at least 12–18 months after migration to cover links embedded in content that does not get refreshed frequently.
For high-volume affiliates whose performance is critical to your program, direct link replacement — providing new Scaleo-generated tracking links and asking the affiliate to update their primary placements — is worth the relationship management effort. A top-tier affiliate who updates their links directly avoids the redirect hop and gives you a clean Scaleo tracking record from the point of the switch rather than a redirect chain that may obscure some click metadata.
Postback Reconfiguration on the Casino Backend
Your casino backend currently fires conversion postbacks to your custom platform’s endpoint. Post-migration, those postbacks need to fire to Scaleo’s receiving endpoint instead. The reconfiguration is technically straightforward — it is a URL change in your casino backend’s affiliate notification configuration — but it must be coordinated carefully with the migration cutover timing to avoid a window where postbacks are firing to the old system after the affiliate commission logic has moved to Scaleo.
Scaleo supports a parallel postback period during migration: your casino backend fires postbacks to both the old custom endpoint and Scaleo’s endpoint simultaneously, and Scaleo logs received events in a review state without firing commissions until the migration team confirms the data is accurate. This parallel period — typically 5–10 days — validates that the full conversion event chain is reaching Scaleo correctly before the old system is deprecated. No conversion events are lost. No affiliates experience a gap in their commission records. The cutover is invisible to affiliate partners.
Switching to Scaleo: What the Migration Actually Looks Like
Scaleo was specifically designed to be migrated to — not just from. The architecture decisions that make Scaleo a strong standalone platform also make it accessible from a wide variety of existing infrastructure, including bespoke custom-built systems. Here is what the migration process looks like in practice for an operator switching from a custom platform.
Week 1–2: Data Audit and Formula Documentation
Scaleo’s migration team works with your engineering team to map your existing affiliate data to Scaleo’s schema. The primary inputs required: a sample export of commission records from your custom system (three to six months of history for review), documentation of your NGR formula including every deduction category and rate, your affiliate account structure including tier assignments and any per-affiliate custom deal terms, and the postback schema your casino backend currently uses to send conversion events.
If your NGR formula is partially or fully embedded in application code rather than documented, the migration team can help reconstruct it from sample commission records — working backward from calculated commission figures to identify the formula components. This is more work than starting from clear documentation, but it is a solved problem with the right process.
Week 2–3: Scaleo Configuration and Historical Data Import
Once the data mapping is complete, Scaleo’s commission plan builder is configured to replicate your NGR formula — including per-affiliate deal variations and tier structures. Historical commission records are imported from your custom system’s export, giving affiliates access to their full commission history in the Scaleo portal from day one rather than only seeing data from the migration date forward.
Your casino backend’s postback schema is mapped to Scaleo’s receiving endpoint. If your custom postback format uses non-standard parameter names or carries custom fields that need to be mapped to Scaleo’s standard parameters, this is handled in the endpoint configuration — no changes to the casino backend postback format are required in most cases.
Week 3–4: Parallel Run and Validation
The parallel postback period runs with your casino backend firing to both systems. The Scaleo migration team validates that conversion events are being received and processed correctly — FTD events triggering the right commission plan, NGR calculations matching the expected formula output, NCO balances tracking correctly from the imported historical starting point. Any discrepancies identified during this period are resolved before the old system is deprecated.
Affiliate communication goes out during the parallel period — letting your partners know that the program is migrating to a new portal, what the new login URL is, and that their historical commission data is already available. Most affiliates experience this as a portal improvement rather than a disruption: the Scaleo affiliate dashboard loads faster, presents commission data in a cleaner format, and provides more detailed NGR breakdowns than most custom-built portals offer.
Week 4–6: Cutover and Redirect Setup
The cutover switches postback delivery exclusively to Scaleo’s endpoint. The old custom tracking domain is configured to serve 301 redirects to Scaleo’s equivalent tracking URLs for any existing affiliate links that have not yet been updated. The old system remains read-accessible for the migration team and for any historical reference queries, but it is no longer the live commission processing system.
From this point, the engineering team that previously maintained the custom platform’s postback handling, commission calculation logic, and affiliate portal has those hours back. Maintenance tickets that previously went to internal engineering now go to Scaleo’s support team. Feature requests that previously went into an internal backlog with uncertain timelines are now addressed through Scaleo’s product development cycle.
Scaleo migration data: Operators migrating to Scaleo from custom-built affiliate platforms complete the full migration in an average of 5.2 weeks from initial data audit to live cutover, with no affiliate-reported commission gaps or tracking outages during the parallel run period. Post-migration, 89% of operators report a reduction in affiliate support tickets within the first 60 days — primarily because Scaleo’s itemized commission statements resolve the “I can’t understand my commission figure” category of tickets that custom portals with limited reporting generate consistently.
The Features You Get on Day One
The migration from custom to Scaleo is not just a platform change — it is a feature addition. The features below are standard in Scaleo and represent capabilities that operators migrating from custom platforms either do not have or would need significant engineering investment to build:
| Feature | Typical Custom Platform Status | Scaleo Day 1 |
|---|---|---|
| Behavioral anti-fraud scoring (player-level) | Not built — manual review only | ✅ Native Anti-Fraud Logic™ with configurable alert thresholds |
| Real-time affiliate dashboard (WebSocket) | Page refresh every 60+ seconds | ✅ Sub-second conversion notifications via WebSocket connection |
| Sub-affiliate / SubID level fraud scoring | Usually not supported | ✅ Per-SubID behavioral scoring and NGR reporting |
| Postback retry queue with exponential backoff | Variable — often single-attempt or simple retry | ✅ Asynchronous queue with exponential backoff and full HTTP delivery log |
| Multi-brand management in single account | Separate deployments or database partitions | ✅ Native multi-brand with unified reporting and per-brand tracking |
| Itemized NGR commission statements for affiliates | Usually a single net figure | ✅ Per-deduction-category breakdown visible in affiliate portal |
| Versioned T&C distribution with acknowledgment logging | Email-based, no audit trail in platform | ✅ In-platform T&C versioning with timestamped acknowledgment records |
| Mobile-responsive affiliate portal | Variable — often desktop-only or poor mobile UX | ✅ Mobile-first responsive design, sub-1.4 second average load time |
| Cross-device attribution (UPID architecture) | Cookie-only or not implemented | ✅ Server-side click storage, UPID-anchored postback chain |
| Deferred deep link attribution for mobile apps | Not built | ✅ Configurable deferred attribution with device fingerprint matching |
Frequently Asked Questions
Will my affiliates notice the migration?
They will notice the portal improvement. The migration itself — the technical cutover from your custom tracking infrastructure to Scaleo — is designed to be operationally invisible: affiliate links continue working through redirects, commission history is imported before the new portal goes live, and the parallel postback period ensures no conversion events are missed during the transition. What affiliates do notice is that the new portal loads faster, their commission statements are more detailed, and real-time conversion data updates without a full page refresh. Post-migration affiliate engagement typically increases rather than decreases, for these reasons.
What happens to historical commission data in my custom system?
Historical commission records are exported from your custom system and imported into Scaleo before the migration goes live. Affiliates see their full commission history in the Scaleo portal from day one — not just data from the migration date forward. The specific data types that transfer cleanly: affiliate account records, commission payment history, active commission plan assignments, and NCO balance starting points. Click event logs from the custom system may or may not be importable depending on how they were stored; if they are not importable, they remain accessible in your custom system as a read-only archive for any historical attribution disputes.
How long does migration from a custom platform take?
The average migration from a custom-built affiliate platform to Scaleo takes 5–7 weeks from initial data audit to live cutover. The variables that extend the timeline: undocumented NGR formula logic that needs to be reconstructed from sample commission records (adds 1–2 weeks), large numbers of unique per-affiliate commission deal variations that each require individual commission plan configuration (adds 1–2 weeks), and casino backends with unusual postback formats that require custom endpoint configuration (adds 0.5–1 week). The variables that compress the timeline: well-documented NGR formula, clean affiliate data export in a structured format, and engineering teams available for timely postback reconfiguration. Migrations where these favorable conditions exist have been completed in under three weeks.
What if my custom platform has unusual NGR calculation logic?
Scaleo’s commission plan builder is specifically designed to handle complex NGR formulas — per-affiliate deduction rates, per-product-line royalty variations, jurisdiction-specific levy deductions, hybrid CPA and RevShare components with different calculation periods. If your custom platform’s NGR logic is unusual, bring the formula documentation (or the commission records we can use to reconstruct it) to the initial migration conversation. Scaleo’s migration team has configured equivalent commission plan logic for operators with significantly complex requirements. The formula may look unusual from the outside; from the platform’s perspective, it is a set of configurable parameters that can be replicated.
Can I run Scaleo alongside my custom platform during the migration?
Yes — and this is the recommended approach. The parallel postback period, where your casino backend fires conversion events to both your existing custom endpoint and Scaleo’s endpoint simultaneously, is a standard part of the migration process. It runs for 5–10 days and serves two functions: validating that the full conversion event chain is reaching Scaleo correctly (FTD triggers, NGR events, withdrawal events), and providing a reconciliation baseline — comparing Scaleo’s calculated commission figures against your custom system’s figures for the same player events, so any formula discrepancies are identified and corrected before the cutover rather than discovered afterward in an affiliate dispute.
The Migration Is Easier Than Maintaining What You Have
The reluctance to migrate from a custom-built platform is almost always rooted in an accurate perception of migration complexity, combined with an underestimation of the ongoing cost of not migrating. The migration is a defined project with a start and an end. The custom platform’s maintenance burden has no end — it compounds with every compliance requirement, every scaling event, and every feature your affiliates wish the portal had. A 5–7 week migration to Scaleo recovers years of engineering overhead and delivers a feature set that would take years to build internally. The affiliate relationship improves. The engineering team gets their time back. The commission calculation is auditable. The fraud detection actually runs.
If you are ready to run the numbers on your own platform, bring your custom system’s commission history and your NGR formula to a technical conversation with the Scaleo team. We will show you exactly how the migration maps, what the configuration looks like, and what the parallel run period would validate — before you commit to anything. Start with the full platform overview or read the migration TCO guide for a detailed cost breakdown by operator size.
