A case study on designing production data infrastructure that moved the commercial needle.

The Problem

Gaming Innovation Group (GiG) is a B2B iGaming platform provider. Its business depends on operators choosing GiG's platform to run their casino, sportsbook, or lottery products.

The challenge was simple to state, hard to solve: GiG wanted to go after larger, more established operators — the kind that already had thousands of active customers. But those operators wouldn't switch platforms unless they could bring their entire customer base with them. Nobody is going to tell 20,000+ players to re-register.

Without a migration path, GiG was effectively limited to greenfield operators — new brands with zero customers. That's a smaller, slower market. The ability to absorb an existing customer base cleanly was the thing standing between GiG and a more valuable class of client.

What I Built

I designed and delivered a data migration framework that could ingest a source operator's full customer dataset — profiles, balances, transaction histories, consents, KYC records — validate it, transform it to fit GiG's data model, and load it into the live platform as real player accounts.

The design constraints were:

• Accuracy — financial data had to be perfect. A single cent off on a customer balance is a compliance and trust problem, not a rounding error.
• Repeatability — this couldn't be a one-off script. It had to work across operators with different source systems, so the variation had to live in configuration, not code.
• Auditability — every record needed clear lineage: what came in, what was transformed, what went out. Regulators care about this.
• A controlled cutover — operators can't absorb extended downtime, and the migration was only one moving part of a larger switchover, so it had to be fast and predictable. A representative run moved 20,000+ records in under 30 minutes.

Here's how it actually came together.

Ingestion: the file spec is the contract

The operator exported their customer base as a defined set of files — customer details, final balances, tags and notes, self-exclusions, consents — and dropped them onto SFTP or S3.

That file specification was the contract, and it's what made the framework repeatable. Rather than write a bespoke integration against each operator's internal database schema, the framework defined the shape of the files it expected, and each incoming operator conformed their export to it. New operator, same pipeline — the difference lived in their export, not in our code. That's what turned "a migration" into "a migration framework."

Transformation and load: NiFi into the PAM

NiFi consumed the files, routed and transformed each type, and made API calls into GiG's PAM (Player Account Management) infrastructure to register the players. Profiles, balances, consents, and self-exclusions all landed as live accounts on the platform — through the same APIs the platform itself uses, so the migrated players were indistinguishable from natively-registered ones.

Validation: catch it before it lands

Before anything was loaded, records ran through data-quality checks — deduplication, non-negative balance enforcement, and the rest of the gates that stop a bad row from becoming a production incident. In a financial system the cheapest place to catch an error is before it ever reaches the live platform.

Reconciliation: the sign-off gate

Accuracy on financial data isn't something you assert — it's something you prove. A separate, automated reconciliation process ran after each migration executed: it sampled the migrated records and checked them against the source before anyone gave the client the go-ahead. That reconciliation was the gate between "the load finished" and "we're confident enough to take this brand live." Nothing went live on a promise; it went live on a check.

Phased by cohort

This didn't run as a single big-bang cutover. The brand's customer base was migrated in cohorts, which phased the risk rather than betting everything on one window. And the data migration was only one workstream inside a larger switchover — frontend migration, DNS, and operational coordination all had to land together. The expected downtime window had to account for the whole puzzle, not just the data.

The architecture

The Outcome

The framework migrated a brand's customer base — balances, consents, profiles, and exclusions — in phased cohorts, with a representative run completing 20,000+ records in under 30 minutes and a reconciliation gate standing between every load and go-live.

More importantly, it changed GiG's commercial positioning. The company could now credibly pursue established operators with existing customer bases — a segment that had previously been out of reach — turning "switch to us" from an impossible ask into a managed process. That opened a new class of client and a new revenue stream.

The capability was highlighted in GiG's quarterly earnings communications, including around the Q1 2024 results, where the ability to onboard larger-scale clients featured in how leadership framed the platform's growth.

What I Learned

Data engineering is a commercial function. This project didn't just move data — it unlocked a market segment. The framework mattered to leadership not because of the technology, but because of what it let the sales team promise. That's the lens I build through now: not "what does this pipeline do," but "what does this make possible for the business?"

Coordination mattered as much as code. I coordinated this end to end — requirements with commercial stakeholders, technical design, development, testing, and delivery — and the data migration was one workstream among several that all had to land in the same window. The hardest part wasn't the pipeline logic. It was aligning what sales promised, what the client expected, and what the data actually looked like.

Data quality is non-negotiable in financial systems. Migrating player balances isn't migrating blog posts; every record carries regulatory and financial weight. Building validation and sampled reconciliation into the framework from day one — as a gate, not an afterthought — is what made it safe to point at a live platform at all.

I'm Julian Calleja, focused on real-time data platforms in iGaming. Get in touch if you want to talk about data infrastructure or iGaming.