How to Move From a Monolithic Platform to a Modular PAM

Moving a live casino off a monolithic platform onto a modular PAM runs nine to eighteen months from the first architecture review to the day the old contract closes, and a mid-size operator should plan for €700,000 to €2.5m across vendor fees, integration work and parallel running. Those ranges are approximate, and most of the spread comes down to one decision: how much of the bonus engine and the CRM you rebuild instead of buy.

Three kinds of operator get real value out of this. A casino doing €20m to €100m in annual GGR whose vendor keeps answering roadmap requests with "not this year". A converged brand that needs one wallet across casino and sport and can't get it from a platform built for one vertical. And a group running two or three brands on separate stacks that wants a single player record. Below €5m GGR the migration usually costs more than it saves, so renegotiate the existing contract instead and come back to this when the numbers change.

Everything below assumes you keep trading throughout. Nobody gets to pause a live casino for a quarter.

What a modular PAM actually changes

Player account management is the system your gambling licence is really attached to: identity and KYC state, the wallet, the bonus engine and its wagering ledger, responsible-gambling controls, and the reporting a regulator asks for. The glossary entry maps the modules; the point here is how they're wired together.

In a monolith those modules share one database and one release train. Changing bonus logic means a regression pass over the wallet, because the bonus balance is a column in the same ledger. In a modular setup each module owns its own data and talks to the others through APIs and an event stream. You can replace the CRM without touching the wallet. That's the whole benefit, and it's also the whole cost, because somebody has to own the wiring that the monolith gave you for free.

The line between the two is blurrier than vendor decks suggest. A "modular" platform that forces its own wallet on you is a monolith with an API in front of it. The practical test: can you swap one module for a competitor's without a rebuild, and does the contract let you take the data with you when you do?

iGamingHub tracks 26 platforms flagged API-first out of 44 in the catalog, and only five of those also expose a headless front end. API-first is close to table stakes now. Being able to run your own front end against someone else's PAM is still rare.

The eight steps, from audit to decommission

1. Audit what the monolith actually owns. Before anything else, write a register of every function currently living inside the platform and what depends on it. Five areas matter most: the wallet (real, bonus and locked balances, the transaction ledger, multi-currency handling), KYC and identity (document store, verification levels, national exclusion register hooks), the bonus engine (offers, wagering requirements, game weighting, expiry, and the history behind each open bonus), CRM and segmentation, and regulatory reporting. For each one, record who owns the data, which regulator relies on it, and what breaks if it goes away for an hour. Games reach the wallet through a game aggregator and each studio's remote game server, so the aggregator contract belongs in the register as a separate line with its own notice period. Time: 4 to 6 weeks. Cost: €20,000 to €50,000 if you bring in an outside architect, which is usually money well spent because internal teams underestimate the bonus ledger.

1. Decide the seam and the order of extraction. You don't extract everything at once. Pick the seam where the monolith is weakest and the dependency count is lowest, then work inward. The usual order is reporting first, then CRM and segmentation, then the bonus engine, then payments, with the wallet and player account last because everything else reads from them. Reporting moves easily because a customer data platform or a warehouse can consume the platform's event feed without writing anything back. The bonus engine is the hard middle: a bonus is a balance plus a rule set plus the history of how it got there, and platforms model that differently enough that mapping is bespoke work every time. Write the order down and get the board to agree it, because the temptation to reorder mid-project is what turns twelve months into twenty-four. Time: 3 to 5 weeks. Cost: internal.

1. Pick the wallet model: single or transfer. This decision sets your integration budget and your reconciliation workload for years. In a single-wallet model, every spin from every studio calls back into the PAM in real time, so the PAM holds one authoritative balance and a mid-size casino sees a few hundred wallet writes a second at peak. In a transfer-wallet model, money moves into a game provider's sub-wallet before play and back afterwards, which cuts the call volume but leaves funds sitting outside the PAM and creates orphaned balances when a transfer half-fails. Single wallet is the right default for a regulated multi-vertical operator: one balance, one audit trail, cleaner responsible-gambling enforcement. Transfer wallet still earns its place where latency to a studio is bad or where a legacy vertical simply can't be re-integrated. Whatever you pick, specify idempotent transaction IDs, rollback semantics and a reconciliation job on day one rather than after the first mismatch. Time: 2 to 3 weeks of design. Cost: internal, but it drives the build estimate in step 5.

1. Contract the modules. Now go to market, and read the cards before the decks. In the iGamingHub catalog, SOFTSWISS is a turnkey platform on a hybrid revenue model, flagged API-first and headless, with 25 licences and certifications across Europe, LatAm, Asia and Africa (MGA, Curacao, ONJN, Kahnawake and Brazil among them), with a 2 to 12 week launch window, 300 payment methods and a 99.999% uptime SLA. EveryMatrix is turnkey on pure revenue share, API-first and headless, MGA, Curacao, Denmark, Argentina and Brazil, 6 to 15 weeks to launch, 180 payment methods, 99.95% SLA, and it sells its modules separately, which is the behaviour you want from a modular vendor. The two are compared side by side in the SOFTSWISS versus EveryMatrix breakdown. GR8 Tech is also API-first and headless, hybrid model, listed with MGA, Curacao, ONJN and Gibraltar, 8 to 16 weeks to launch, 160 payment methods, 99.96% SLA. Amelco is the North America case: turnkey, fixed fee rather than revenue share, API-first and headless, licensed in New Jersey, Pennsylvania, Colorado and Indiana, sportsbook rather than casino, 12 to 24 weeks to launch and no crypto support. Not every API-first vendor is headless: NuxGame is flagged API-first with a 3 to 8 week launch window but ships its own front end, and 24 payment methods against the 150-plus its larger rivals list. Negotiate the exit at the same time as the entry, using the criteria in the platform selection guide: data export format and cost, wallet portability, notice period, and what happens to bonus state if you leave in year two. Time: 8 to 14 weeks. Cost: €30,000 to €80,000 in legal and advisory, plus setup fees.

1. Build the integration and orchestration layer. The wiring is the project. You need an API gateway in front of the modules, an event bus carrying the player lifecycle (registered, verified, deposited, wagered, bonus granted, limit set, excluded), and an orchestration service that owns the sequences no single module can own alone, such as "deposit succeeded, so credit the wallet, evaluate the bonus, notify the CRM, and write the AML record". Three things separate teams that ship this in four months from teams still on it a year later: idempotency keys on every write, a replayable event log so a failed subscriber can catch up without a manual fix, and an automated reconciliation that compares wallet totals against the payment ledger every night from the first day of the build. Aggregator integration sits here too, and the practical differences between aggregator models are covered in the aggregator comparison. Time: 4 to 8 months, overlapping steps 6 and 7. Cost: €250,000 to €900,000 depending on how much you build in-house.

1. Migrate players and balances with a traffic slice. Never move the whole player base at once. Export a full snapshot into the new PAM, run a dry migration in a staging environment, and reconcile three things line by line: cash balances, open bonus state including remaining turnover, and KYC verification level plus any self-exclusion or limit currently in force. A player who was verified on Friday must be verified on Monday, and a self-excluded player must stay excluded even if the mapping for that flag is imperfect. Then go live on a slice: 1% of low-value players first, hold for two weeks, then 5%, then 20%, then the VIP segment last with an account manager watching each one. Dual-write during the slice period so the old stack stays authoritative until you're ready to flip. Budget for the reconciliation gap you will find, because every migration finds one. Time: 6 to 12 weeks. Cost: €120,000 to €350,000.

1. Run both stacks in parallel and cut over. Parallel running is the expensive part nobody puts in the business case: two platform fees, two support rotas, two sets of reports for the same month. Plan two to four months of it. Freeze new features for the final four weeks so the two stacks stay comparable, then pick a low-traffic window for the flip and rehearse the rollback path before you need it. Tell your regulators before, not after. Under the UK Gambling Commission LCCP, licensees must notify key events and changes to their operating arrangements, and the Malta Gaming Authority expects material changes to a licensee's setup to be notified and, in some cases, approved before they happen. In Ontario, iGaming Ontario operators work to registration standards that assume the regulator knows what stack the games run on. Building the notification into the plan costs a week; discovering the requirement after cutover costs a licence review. Time: 2 to 4 months of overlap, cutover in a single weekend. Cost: €150,000 to €400,000 for the duplicate running.

1. Decommission and renegotiate. After cutover, resist the urge to switch the old platform off on Monday. Keep it readable for one full reporting cycle so finance can close the month against both systems, then export everything you're legally required to retain, typically five years of AML and transaction records depending on the market, into your own storage rather than the vendor's. Confirm in writing that the old contract has terminated and that the vendor has deleted personal data it no longer has a basis to hold. Then go back to the new vendors with twelve months of real volume and renegotiate: the revenue share you signed as an unknown quantity is rarely the one you deserve once the traffic is proven. Time: 6 to 10 weeks. Cost: €20,000 to €60,000, offset by whatever the renegotiation wins back.

Stages, time, cost and owners

Add the early-termination fee if you're leaving before the contract ends. That line alone runs €150,000 to €500,000 for a mid-tier operator and is the single number most likely to decide whether you move this year or wait for renewal.

Common mistakes

• Starting with the wallet. It's the module with the most dependencies and the least tolerance for error. Extract reporting and CRM first, learn how your event stream behaves under real load, then touch the ledger.
• Treating bonus state as data. Open bonuses are rules plus history, not numbers. Migrations that map only the balance produce players whose wagering requirement resets or doubles, and both outcomes end up in front of a regulator.
• Buying "modular" without testing replaceability. Ask each vendor, in writing, what it costs and how long it takes to remove one module and keep the rest. A vendor that can't answer is selling a monolith with an API.
• Skipping parallel running to save money. The two to four months of duplicate fees is the cheapest insurance in the project. Operators who cut straight over usually pay the saving back in churn within a quarter.
• Migrating VIPs early. They generate the most revenue and complain the loudest. Move them last, with a named account manager watching each account through the first week.
• Forgetting the regulator until cutover week. Notification requirements are a planning item, not a formality, and getting one wrong turns a technical project into a licence problem.

Migration checklist

• Dependency register complete for wallet, KYC, bonus engine, CRM, reporting and the aggregator contract, with notice periods on every line.
• Extraction order agreed at board level and written down, with a rule about who can change it.
• Wallet model chosen, single or transfer, with idempotency, rollback and nightly reconciliation specified before the build starts.
• Vendor contracts include data export format, wallet portability, notice period and year-two exit costs, not just the revenue share.
• Event bus, API gateway and orchestration service built with a replayable log and automated reconciliation running from day one.
• Dry-run migration reconciled line by line on cash balances, open bonus state and KYC or exclusion status.
• Traffic slice plan set at 1%, 5%, 20% and finally VIPs, with dual-write and a tested rollback at each stage.
• Regulator notifications filed for every licensed market before the cutover date.
• Parallel running budgeted for two to four months and a named cutover owner appointed.
• Retention data exported to your own storage, old contract confirmed terminated in writing, renegotiation booked for month twelve.

If the terminology in vendor contracts is the part slowing you down, the operator glossary covers the terms that show up in platform agreements.