This is a sports & gaming problem we approach through our Platform to Platform service line.
The problem
You run several brands. Maybe they came from acquisitions, maybe they serve different jurisdictions or different customer segments. Each one sits on its own infrastructure, with its own database, its own administration screens and its own reporting.
At two brands, that is a reasonable arrangement. Somewhere around the fifth, the arithmetic turns. Infrastructure spend scales with brand count, and because every brand peaks at the same moment — race day is race day for all of them — you are provisioning peak capacity several times over for load that arrives once.
The administration cost is the one that hides. A configuration change, a market suspension, a compliance update, a release: each has to be applied per brand, by someone, correctly, every time. That shows up as headcount rather than cloud spend, so it does not appear in the infrastructure review that triggered this project.
And nobody sees consolidated position. A customer active across three brands is three unrelated customers. Exposure is reconciled overnight, which means the information arrives after the window in which it could have changed a decision.
Why it’s hard
Retrofitting tenancy is not a refactor. Tenant identity has to reach pricing, risk, wallet, settlement, content, reporting and audit. Every one of them. Miss it in a single query path and one brand can see another brand’s liabilities — a disclosure, not a bug.
Convention is not enforcement. Passing a tenant id through application code and trusting every developer to filter on it works until the first person forgets. Isolation has to be a property of the data access path, so that the unsafe query fails rather than succeeds quietly.
The blast radius changes shape. Per-brand infrastructure has a real virtue: an incident affects one brand. Consolidation trades that for cost efficiency, which means you now need noisy-neighbour controls, per-tenant rate limits and resource ceilings that did not previously matter, plus the ability to degrade one tenant rather than the estate.
Configuration surface grows faster than you expect. Every difference between brands becomes a configuration axis: branding, currency, language, time zone, wallet and payment providers, market availability, bet type availability, jurisdictional rules, commission and agent structure, limits, bonusing. Deciding what may differ per tenant is a product decision that engineering cannot make for you, and it is the decision that determines whether the platform stays one platform.
The migration runs against live money. Cutover happens on a system settling real transactions, under jurisdictions that do not accept “we were mid-migration” as an account of a discrepancy.
How we approach it
Data-level tenant isolation. Every tenant runs on shared infrastructure with isolation enforced at the data layer. Where a product needs to serve multiple organisations, we design tenant boundaries early across identity, storage, background jobs and reporting. A tenant column alone does not establish isolation.
Per-tenant configuration out of one deployment. Branding, front-end layout, wallet integration, currency and exchange rate handling, language and localisation, time zone alignment for racing across jurisdictions, betting rules and market availability are configuration against a shared engine. Brands differ in presentation and offering; they share the arithmetic.
Helm-chart tenant onboarding. New tenant deployment is a chart, applied in minutes. That number is only interesting because of what it removes: onboarding stops being a project and becomes an operation, which changes how commercially aggressive you can be about a small brand.
One management console. Operators administer every tenant from a single surface — configuration, markets, suspensions, releases — instead of repeating an operation per brand and creating an opportunity for one brand to drift out of configuration with the others. Reducing that repetition is where the operational cost saving actually comes from.
One real-time reporting surface across tenants. Money in, exposure and risk position across every brand, visible as it happens rather than assembled overnight. The same surface makes player cohorts identifiable — fraud signals, VIP behaviour, bonus hunting — while they are still behaving that way, instead of in a retrospective audit.
Agent and commission hierarchies per tenant. Multi-layered agent networks with sub-agent visibility, per-agent limits and settlement cycles, held per tenant rather than as a global model, because two brands rarely share a distribution structure.
Auto-scaling against the shared peak. Kubernetes with per-tenant resource policy, so capacity is managed across the estate. Shared services and reduced duplication contribute to savings; simultaneous peaks still require capacity for the combined demand.
What we would not do. We would not consolidate a tenant whose licence requires physically separated data. We would not run per-tenant release trains. And we would not consolidate reporting before consolidating identity — if a customer is still three records, a single reporting surface just shows you three records faster.
What it takes
A written inventory of what differs per brand. Every difference, including the ones that exist because of a decision made four years ago that nobody defends any more. This document is the actual specification, and producing it is usually the longest part of the discovery.
A decision on the isolation model. Row-level, schema-level or cluster-level separation, made against your licence conditions rather than against engineering preference. This is the one architectural choice that is expensive to revisit.
Migration sequencing. Smallest brand first, parallel running, reconciliation against the incumbent before the incumbent is switched off. Expect to run both for a period.
Someone with the authority to say no. Consolidation succeeds or fails on whether a brand’s request for a bespoke behaviour can be answered with a configuration option or a refusal. Without that authority, you will end up with one deployment per brand again, in a shared repository.
Where this has been done
This is a shipped reference. We built a multi-tenant tote and fixed-odds betting platform between 2020 and 2025, and we continue to develop, deploy and operate it. Tenants share infrastructure with data-level isolation, tenant deployment is Helm-driven and completes in minutes, and administration and reporting are consolidated into single surfaces.
The confirmed outcomes on that engagement are that multi-tenancy cut infrastructure cost substantially against per-tenant infrastructure, that the single management console reduced operational cost, that one reporting portal improved operational efficiency across many tenants, and that player-risk cohorts became identifiable in flight. The pattern is not specific to betting. Many tenants, per-tenant infrastructure, no consolidated view, and behaviour only visible in aggregate is a shape that can also arise in mining telemetry across sites, claims across underwriters, service delivery across agencies, and retail across store estates.