Migrating a market, not a screen
Brazil's new regulation gave every existing player a hard date to re-verify. The migration started collecting data months before the new experience existed, and closed on the deadline without major issues.
- Principal
- Product Design Manager, Kaizen Gaming
- Sep 2024 – Jan 2025
- Entire Brazilian customer base
My role
Principal · Product Design Manager, Kaizen Gaming. I owned the migration architecture, the end-to-end experience, its flows and unhappy paths. Product, Compliance, Engineering, KYC vendors and the Brazil team owned feasibility, coordination and implementation.
A legal date, and a customer base that had to cross it
In September 2024, Brazil published the rules for the transition into its regulated betting market. The transition period started on 1 October, and the regulated market took effect on 1 January 2025. Every existing player had to meet new requirements before that date: identity checks with liveness, proof of address, and a valid bank account.
This was not a product improvement. The company's ability to keep operating legally through its Brazilian entity depended on it.
3
The problem was time, not the flow
The window was three months. A complete migration experience could not be built before data collection had to start. The product also carried technical debt, and players would arrive in very different states: some data present, some missing, some waiting on external verification.
One migration flow, forced on everyone at once, would have met the deadline on paper. It would also have depended on an experience that did not exist yet, and pushed the whole customer base through a single wall in the final days.
Four decisions that shaped the migration
- Start before the experience exists
- Orchestrate, don't rebuild
- Treat the wizard as a state machine
- Raise the pressure only as the date approached
Start before the experience exists. Many required data points were already editable in My Account, and the product already had a mechanism, "follow the dot", that pointed people to missing profile information. I proposed using it immediately. Collection started in the first days of the transition, while Engineering built the rest.
Orchestrate, don't rebuild. Identity verification, contact verification, KYC and profile data collection already existed as capabilities. The only new piece was a layer that tied them together. The migration wizard orchestrates existing flows instead of redesigning them. That kept the build inside the window.
Treat the wizard as a state machine. Not every step resolved immediately. An OTP confirms in seconds; an external verification can stay pending. The wizard had to know, for every player, what was already done, what was missing and what was waiting, and show only the steps that remained. Players could leave and return without losing their place.
Raise the pressure only as the date approached. The migration moved through three stages: soft guidance in the profile, then a wizard that appeared after login and could still be dismissed, and finally a mandatory migration after login in the last two to three weeks before 1 January.
- Soft guidance in the profile
- A wizard after login, still dismissible
- Mandatory, in the last weeks
The hard parts
The unhappy paths became the most collaborative part of the work. As limits surfaced around verification vendors, asynchronous states and what data could be processed, I adapted the flows to what was feasible with Engineering. Several compromises were deliberate: the job was to know where the experience could bend without breaking the regulatory objective, and where it could not.
The outcome was binary. Players who completed the migration kept using the product, including deposits. Players who did not could no longer use the service, so the design also covered the operational path: automated withdrawal or refund of eligible remaining balances.
What changed
The migration covered the Brazilian customer base and completed within the regulatory timeline, without major issues. No reliable metrics were kept that could be quoted here.
The trigger mechanism later carried into the registration redesign, where regulatory triggers decide which steps a player sees in each market.
- 1 Jan
- 3
Reflection
I would have settled the state model with Engineering even earlier, measured every stage from day one, and formalized the approach as a reusable migration framework: detect the customer's state, find what is missing, collect it progressively, orchestrate existing capabilities, and enforce only when the date requires it.