A case study on building a repeatable process for migrating an operator’s player accounts.

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.

For an established operator, a reliable migration path is part of the decision to switch platforms. The framework addressed that practical barrier: bringing existing player accounts onto GiG’s platform.

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

A separate, automated reconciliation process ran after each migration. It sampled migrated records and checked them against the source before the client received the go-ahead. This was a sign-off gate alongside the earlier validation checks; sampling did not independently verify every migrated record.

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.

The framework made onboarding established operators a more repeatable process. That connected the engineering work to a commercial need: helping prospective clients bring their existing customer base with them.

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 connected data movement to the practical needs of operator onboarding. 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.