Planning Data Migration for a Live iGaming Platform

A migrated platform can display the right total balance and still put money in the wrong player's account. It can copy every deposit while losing the operation identity that prevents a delayed callback from crediting that deposit again. Row counts alone do not establish that the business has moved safely.

For engineers, finance and operations planning a live iGaming migration, the central task is to preserve obligations and establish one authoritative writer. This article turns that task into a data contract, reconciliation checks and a cutover sequence. The balance example is hypothetical; the plan must be adapted to the actual ledger, providers and approved operating requirements.

Inventory the obligations that must survive the move

Begin with a migration inventory organised by business responsibility. For each dataset, identify its authoritative source, owner, dependencies, write paths, retention decision and acceptance check. Include background jobs and external events; disabling the player interface does not stop the platform changing.

• Money: ledger history, balance categories, holds, unsettled bets, deposit and withdrawal operations, reversals and reconciliation cases.
• Player controls: identity links, verification evidence and status, account restrictions, self-exclusion, limits and relevant consent records.
• Rewards: accepted bonus terms, rule versions, progress contributions, expiry, loyalty balances and unresolved awards.
• Operations: provider transaction identities, idempotency records, pending commands, event queues, approvals and support cases.
• History and access: audit records, report references, documents, authentication data and the means to retrieve retained history.

Classify each dataset as migrated into live operations, retained in a controlled archive, rebuilt from an authoritative source, or excluded under an approved policy. Record the reason. An archive is useful only if support, finance and authorised reviewers can find a historical transaction and explain its relationship to the new account.

Define the scope in the context of platform modernization or a discovery and architecture stage. Retention, privacy and market-specific obligations need the operator and appropriate advisers. Do not turn migration convenience into a decision to keep every personal record forever or discard evidence needed for an open obligation.

Map meaning before transforming rows

Version the transformation rules and keep a stable mapping from old identities to new ones. Scope identifiers by operator, provider and object type where necessary. A transaction ID that is unique at one provider may collide with another provider's ID. New account identifiers must still lead support back to the original ledger and external references.

For each field, record its source meaning, target meaning, conversion rule and treatment of invalid data. Pay particular attention to:

• Money: currency, precision, minor units, sign conventions and the distinction between available, held, bonus and total balances.
• States: pending, confirmed, reversed, cancelled and disputed outcomes. An unknown source state must not become successful through a default value.
• Time: time zone, event versus processing time, deadline semantics and precision needed to preserve order.
• Controls: whether a limit is absent, zero, unlimited or inherited. A null-to-zero conversion can reverse its meaning.
• References: parent operations, reversal links, provider identities and the accepted versions behind active bonuses.

Quarantine invalid records with a reason and an owner. Correct the authoritative source through an approved procedure, or use an explicit, reviewable migration adjustment. Do not silently merge players, manufacture missing ledger entries or remove a restriction to make an import pass.

Authentication deserves a separate compatibility plan. OWASP's password storage guidance covers hashing and legacy upgrades. Preserve supported hash parameters securely; use a reviewed authentication upgrade or reset path where required. Do not export plaintext passwords or treat hashing an existing hash as an automatic conversion to the new scheme. Test access with controlled accounts and exclude sensitive credentials from migration reports.

Join the initial copy to a complete change history

A live copy needs a documented relationship between the starting data and subsequent changes. An initial export taken table by table without coordinated consistency can mix a wallet before an operation with its ledger after that operation. More copying does not resolve the missing boundary.

The MySQL InnoDB documentation explains transaction snapshots: under REPEATABLE READ, consistent reads in one transaction use the snapshot established by its first consistent read; READ COMMITTED uses a fresh snapshot for each consistent read. Schema changes introduce exceptions. Choose a backup or migration method with verified consistency and change-log boundaries for your source; a timestamp written next to an export is not that proof.

For an initial load followed by change data capture, or CDC, record the capture start, copy progress and durable apply positions. Retain the source log long enough for the supported outage and replay window. Test restarts, overlapping delivery, deletes, large transactions and the treatment of schema changes. Reapplying a captured change must not create a second financial effect or overwrite a newer state with an older one.

Keep the target isolated from normal business writers during copy and validation. Importing a settled deposit is state transfer, not an instruction to credit the player again. Review triggers, schedulers and outgoing event processors so that loading historical rows cannot send payments, grant rewards or publish live events. Rebuilt caches and indexes must derive from the same accepted data.

Monitor capture and target application separately. AWS DMS monitoring distinguishes source and target latency; a zero source latency can occur when no new log events are found. Low lag is useful operational evidence, but cutover requires proof that the agreed boundary has been applied and reconciled.

Reconcile financial and operational state at the same boundary

Validate structure, transformed values and business invariants separately. Counts reveal missing or duplicated records. Key and reference checks reveal broken relationships. Deterministic comparisons of canonical values can reveal field differences, provided both sides use the same encoding, precision, null rules and approved transformations.

AWS DMS validation compares source and target rows, adds workload and reports pending or suspended comparisons. It has key requirements and limitations. Treat an unvalidated critical row as unresolved, not as a successful match. For transformed schemas, supplement tool checks with explicit business comparisons.

Hypothetical balance check: assume one currency, integer minor units, and a cash total consisting only of available and held funds. At the agreed boundary:

• Source account A has 8,000 available and 2,000 held: cash total 10,000.
• Source account B has 2,500 available and 500 held: cash total 3,000.
• The source aggregate is 10,500 available plus 2,500 held, giving 13,000 cash.
• The target gives A 9,000 available and 2,000 held, and B 1,500 available and 500 held. Its aggregate is also 13,000, with the same aggregate available and held amounts.

The aggregate passes while A has gained 1,000 and B has lost 1,000. Reconcile by player, currency and balance category, with the mapping and ledger history behind each amount. Keep bonus funds separate and never sum unlike currencies into one apparent control total. If the target imports an opening balance alongside historical postings, prove how history is marked or represented so that it cannot increase that opening balance again.

Also compare open obligations: each held amount must relate to an identifiable operation; unsettled bets retain settlement and reversal references; pending withdrawals retain their provider state; restrictions and limits retain their meaning. Check duplicates, orphan references, missing idempotency records and whether an active bonus has its accepted rule version.

Run final checks against the same logical boundary on both sides. Comparing a frozen source with a target that has already accepted new transactions creates differences that are neither proof of corruption nor evidence of safety. For multiple databases or event streams, record the relevant set of checkpoints and how cross-domain obligations remain consistent. Block cutover for unexplained financial or critical control differences.

Switch write authority with an executable runbook

The runbook should name an owner, precondition, action, evidence and abort response for every step. Agree the allowed service interruption, stop conditions and decision authority before the migration window. A workable sequence is:

1. Confirm readiness: approved mapping version, successful rehearsal, available recovery evidence, provider contacts and staffed finance, support and engineering roles.
2. Quiesce business writes: stop new affected actions under the approved product policy, drain or inventory in-flight work, and fence scheduled and manual writers. Keep a durable route for incoming provider events according to the provider's acknowledgement contract.
3. Record the final source boundary: after the controlled source commits, record database and event positions and the remaining open operations. Keep the source protected against further unauthorised writes.
4. Catch up and reconcile: prove target application through those positions, inspect excluded or failed records and run the agreed financial and control checks. Abort before activating the target if the evidence does not pass.
5. Transfer authority: enable only the designated target writers, verify old workers and credentials cannot continue writing, and route commands and callbacks through the agreed ownership boundary.
6. Open a controlled scope: observe deposits, play, withdrawals, reconciliation and restrictions with staffed exception handling. Expand only when the agreed acceptance evidence remains valid.

Pending provider operations need an explicit owner across the switch. Preserve the same business and idempotency identities when a delayed callback is processed. Do not acknowledge an incoming event that must be retained unless durable acceptance and the provider contract support that acknowledgement. A maintenance page is not a substitute for controlling workers, queues and direct database access.

Record actual times, checkpoint evidence, reconciliation results, approvers and deviations in the runbook. If the cutover window or log-retention margin is being exhausted, stop under the agreed rule. An unsupported gap in the change history requires a verified recovery or new baseline, not an optimistic resume.

Separate rollback before and after new writes

Define the recovery boundary before starting. Before the target accepts new business writes, returning to the protected source may be feasible if it is still authoritative and all captured external events and in-flight effects are accounted for. Prove that path in rehearsal, including how traffic and event ownership return.

After the target has accepted new writes, pointing the application back to an old backup can lose deposits, settlements or withdrawals. Options include repairing the target and moving forward, or a separately rehearsed reverse migration that preserves all new obligations. Reverse replication is a design capability to prove, not a setting to improvise during an incident.

If reverse migration is supported, test the reverse transformations, identities, schema compatibility, financial postings and restrictions. Some new target states may have no valid representation in the old system. Fence writers again, establish a common recovery boundary, reconcile the delta and obtain the designated approvals before transferring authority back.

Restoring data does not undo an external payment. Any correction to a confirmed financial outcome needs a traceable, authorised compensating operation and reconciliation with the relevant provider. Keep the original evidence. The recovery decision must identify who owns player communication, unresolved operations and the final financial record.

Rehearse the failures that could stop the migration

Rehearse with representative data volume and write behaviour in a controlled environment. Use privacy-approved data and appropriate access; a small clean sample may miss the oldest records, unusual currencies, long-running rounds and historical rule versions that cause the real migration to fail.

Test interruption during the initial load, restart during capture, repeated changes, an out-of-order event, a missing log segment, a mismatched held balance, a late provider callback and a target failure after the first new transaction. Include support retrieving history and a restricted player attempting an action. Record actual copy, catch-up, validation and recovery durations; do not infer the maintenance window from export speed alone.

Keep a migration evidence pack: inventory, versioned mappings, reconciliation queries and results, checkpoints, exception decisions, the completed runbook and recovery rehearsal. Assign ownership of post-cutover reconciliation and old-system access. Retire the old environment only after outstanding obligations, history access, retention decisions and recovery needs have been resolved.

The successful result is a platform whose current state and remaining obligations can be explained after the move. Migration completion should rest on that evidence, not a green job status or a copied row total.

For adjacent decisions, see wallet and ledger design, modernization without a full rewrite, and a practical strangler migration roadmap. Modular monolith and microservices choices clarify system boundaries, while peak-traffic planning addresses the load under which capture and validation must coexist with operations.

• Every migrated, archived or excluded dataset has a reviewed meaning, owner and acceptance check; open obligations remain traceable.
• The final source boundary is recorded and applied at the target, with no unexplained financial differences or lost critical player controls.
• One designated system owns writes, and workers, queues, callbacks and manual access obey that boundary.
• Recovery has been rehearsed for both sides of the first new write, including external effects, new obligations and retained evidence.