Strangler Migration for iGaming: Transfer Responsibility, Then Retire the Old Path

Switching the withdrawal screen to a new service does not transfer every withdrawal. A provider can still confirm an operation accepted by the old system, a scheduled job can still update its records, and support can still depend on its history. A migration is incomplete when the new interface works but those responsibilities have no clear destination.

Martin Fowler’s Strangler Fig account describes gradual replacement through manageable parts and temporary architecture that lets old and new coexist. For an operating iGaming platform, the practical task is to transfer a bounded capability without losing accepted work or creating a second financial authority.

This guide gives architects, engineering leaders and operations owners a roadmap from the first boundary to legacy retirement. It uses hypothetical withdrawal operations to explain routing and recovery. The stages are planning recommendations, not a universal timetable, a requirement to adopt microservices or proof of permission for a particular operator.

Choose a capability and state what will remain

Begin with an observed constraint: changing a payout workflow requires an unrelated release, an obsolete adapter blocks a provider upgrade, or support cannot trace unresolved work. Name the outcome you want and the evidence that will show improvement. Compare a targeted repair, an internal module boundary and a replacement before assuming extraction is necessary.

For our example, the proposed slice moves withdrawal orchestration for an agreed scope into a new component. The existing wallet remains the only authority for financial entries through its controlled interface. Identity, player restrictions and provider arrangements remain dependencies. This is not a wallet migration, and the new component does not acquire permission to edit balances directly.

Record included brands, routes, commands, data, jobs and operating duties, plus exclusions. If you cannot identify how a withdrawal completes after the first request, the slice is not yet bounded. A modular-monolith versus microservices decision helps choose the deployment boundary; incremental replacement is possible without turning every capability into a separate service.

Use platform modernization for the wider engagement and the legacy modernization guide for comparing candidate changes. The roadmap here starts once a useful first boundary can be defined and investigated.

Control every entry point at the replacement boundary

Find every route into the capability: player and staff requests, provider callbacks, workers, scheduled jobs, administrative scripts and direct database writes. A new gateway does not control a job that bypasses it. Either move those paths behind the boundary, constrain them explicitly or leave the affected responsibility outside the proposed transfer.

Microsoft’s Strangler Fig guidance describes a facade routing between legacy and replacement components and warns that it can become a bottleneck or a single failure point. Treat the routing layer as a service to operate, with tested capacity, access controls, monitoring and versioned configuration.

Define routes by business responsibility rather than random requests. Use the approved scope for a new command; use the recorded operation owner for a callback or continuation. Preserve the original identity and relevant provider account. Route changes must not move an operation merely because its next message arrived after a configuration update. A traffic rule alone does not establish admission ownership; the acceptance process must prevent both implementations from accepting the same operation.

An adapter should translate the old contract into explicit meanings, not disguise unresolved states as success. Record permitted fields, errors, retry behaviour and version compatibility. For supplier-facing work, connect the boundary to the platform integration scope, including commercial access and the provider’s actual protocol.

Separate routing for an unmigrated capability from retrying an uncertain command. A timeout after possible acceptance is not permission to send the same request to the other implementation. Preserve the uncertainty and investigate through the responsible path; automatic fallback can otherwise create an additional payout.

Keep unfinished operations with an explicit owner

Suppose withdrawal 41 was accepted by the legacy orchestrator before the transition. After new admissions move to the replacement, withdrawal 42 is accepted by the new orchestrator. Both use the same authoritative wallet interface, but each retains its own recorded orchestration owner. The numbers are illustrative operation identities, not amounts or sequence assumptions.

A late provider confirmation for 41 must reach its legacy owner, or a deliberately transferred owner with verified state and references. It must not become a new request in the replacement. A retry for 42 must remain connected to 42, not be treated as a fresh withdrawal by the old service when routing changes.

• Admission: durably record operation identity, scope, selected owner, provider account, available correlation references and relevant terms before dispatching actions that can change funds or trigger an external action. Attach later provider references to that same operation.
• Continuation: authenticate and match callbacks, scheduled work and staff actions to the original operation. Unknown or contradictory evidence needs an investigation owner.
• Money: apply a permitted wallet command through the existing financial authority with the original operation identity and verified scope. Repeated evidence must not repeat its financial effect.
• Restrictions: preserve accepted context without assuming that it grants permission for every later action. Apply the current controls required by the actual action and operator rules.

Keep this ownership record durable and usable by both routing and support. If open work cannot remain in the old component, plan an explicit transfer: reconcile its state, references and unresolved actions, stop competing processing and verify the receiving owner. A migration label is not that transfer.

Move data without creating competing authorities

Distinguish authoritative business state from a copied read model. During comparison, the replacement may consume a projection while the legacy component still owns the underlying changes. That copy does not become permission to accept withdrawals or decide player eligibility. Show its freshness and use the responsible system for decisions that require current state.

Join the initial copy to a complete change history using the actual database or connector contract. Record the capture boundary, ordering and replay behaviour, restart position, retention limits and how deletes and schema changes are handled. Reconcile at a documented common point; comparing two moving datasets can produce a mismatch caused by timing or hide a missing change.

For a concrete database example, PostgreSQL 18 logical replication copies table data and then applies subsequent publisher changes. Its documented restrictions include schema changes and sequence state that are not replicated. Row replication alone therefore does not establish readiness to write on the destination. Verify the actual engine, version and migration mechanism.

When application state and a notification must be recorded together, AWS’s transactional outbox guidance describes saving the state and outbox entry in one transaction, with later publication. It also warns about duplicate delivery. Consumers need safe repeat handling; an outbox is not a guarantee of one business effect across providers and wallets.

Avoid independent business writes to both stores as a shortcut. Copying an authoritative change is different from letting both implementations decide it. Reconcile identities, amounts and currencies, open work, holds, restrictions and relevant history according to the selected slice. The live data migration guide develops those checks; correct totals alone do not prove correct ownership.

Prove coexistence before moving live commands

Make comparison safe before calling it a parallel run. Start with controlled fixtures and recorded cases suitable for the approved environment. A shadow evaluation may calculate what the replacement would return, but it must not send real provider commands, create wallet entries or trigger player messages. Enforce that boundary rather than rely on an informal promise from the test team.

Compare meaning, not identical JSON alone. Is the same operation still unresolved? Does a denied action remain denied? Can support find the same provider reference? Document intentional differences, such as a corrected status mapping, with the relevant decision owner. An unexplained financial or access difference blocks expansion; the legacy result is evidence to examine, not always the correct specification.

Rehearse delayed and repeated callbacks, a crash after durable acceptance, capture interruption, an unavailable dependency, concurrent staff work and a routing change during an open operation. Verify that neither replay nor the comparison process creates a second effect. Test the identity, permission and owner boundaries alongside the happy path.

Only then move a bounded, approved set of live admissions. Keep operation ownership stable, check the actual controls and supplier conditions, and name support and incident owners. A small audience reduces exposure but does not prove that the remaining obligations are safe. Inspect unresolved work and financial evidence alongside errors and latency.

Run cutover with two different recovery plans

Write an executable cutover plan with a decision owner, technical actions, evidence, pause conditions and communication. The plan should say what is being transferred and what remains with the old component. A presentation saying “route traffic to the new service” is not enough.

• Prepare: demonstrate the selected slice, compatible contracts, operation-owner routing, capture recovery and the receiving team’s procedures. Confirm external dependencies and approved controls.
• Establish the boundary: prevent old acceptance of new withdrawals in the selected scope while preserving the processing of already accepted work. Fence a former writer only for a data responsibility actually being transferred; in this example the wallet retains its authority. Catch up and reconcile required data at the agreed boundary before allowing the new responsibility to accept work.
• Switch and observe: enable the selected new responsibility through controlled configuration. Prevent competing admission or writes; verify accepted operations, provider evidence, wallet effects and support access. Hold expansion when a required condition is unproven.

Before the replacement accepts new work, returning to the old route may be feasible if the team proves that no new durable obligation or external effect occurred and that the old path is still compatible. Rehearse that case rather than assume it.

After the replacement accepts withdrawal 42, redirecting requests does not erase 42 or make the legacy orchestration records current. Recovery must account for that operation and any other new state. Options can include keeping the new owner while pausing further admissions, or a tested transfer with reconciliation and controlled replay. Select the option the actual contracts and records support.

Restoring an old backup and changing a route can lose new obligations. Retaining a synchronized copy is also insufficient if the old code cannot interpret its states or safely resume pending actions. Set the recovery choice from verified semantics and operating capability, not merely from the availability of a feature flag.

Retire the old path and review the next slice

Legacy retirement is a separate acceptance decision. Retire only the orchestration paths actually replaced; the wallet retained in this example remains in operation. Check that the migrated capability no longer depends on its old commands, internal callers, jobs, direct writers or provider callback path. Complete or deliberately transfer open obligations and unresolved cases. Confirm that retained history remains retrievable by authorised staff under the approved retention policy.

Exercise the proposed retirement safely in an agreed environment and inspect dependency evidence over a period chosen for the real workflow. A quiet endpoint during a short observation does not cover a delayed provider response or infrequent scheduled job. Disable remaining authority deliberately; do not delete financial or audit history to make the architecture diagram cleaner.

Remove temporary adapters, replication and infrastructure only when their consumers and recovery duties have been accounted for. If an adapter must remain for an old client, give it an explicit maintained role. Track the operating cost and owners of the remaining transition so that coexistence does not become an unexamined permanent architecture.

Compare the result with the original constraint: can the team change the withdrawal capability with the intended independence, can support resolve the same cases, and has the old dependency actually disappeared? Then choose the next slice from current evidence. If you cannot control entry points, afford coexistence or keep the legacy system supported, reconsider a wider replacement or another intervention.

When assessing a replacement supplier, use the platform demo guide to request an open-operation and recovery walkthrough. A successful new screen is useful evidence of behaviour, but it does not prove routing completeness, a safe ownership transfer or the retirement of the old system.

• Boundary accepted: the capability, entry points, dependencies, remaining financial authority and intended improvement are explicit and reviewable.
• Coexistence proven: safe comparison, compatible contracts, durable operation ownership and complete change capture have been demonstrated within the proposed scope.
• Transfer controlled: one authority accepts each responsibility; evidence, reconciliation, staff procedures and recovery before and after new work are agreed.
• Retirement justified: old callers, writers and open obligations are resolved, required history is accessible and temporary dependencies have an accountable disposition.