Migrating approximately 30k users between partners

A partner change inside a live product

A production platform needed to move approximately 30k users from one partner to another. Mobile app users were already using the system, and actual fund transfers were involved. That made the work an operational transition as well as a data migration: we had to account for the behavior of a live product, partner rate limits and the readiness of the receiving system.

Plan for interruption and recovery

I worked with the team to plan the migration scripts around controlled execution. They needed to be pausable, resumable, retriable and idempotent: stopping or repeating work should not leave us guessing what had happened or cause an operation to be applied twice. Partner rate limits also shaped how we could progress through the migration. The execution plan had to support recovery from partial progress rather than assume that a single uninterrupted run would succeed.

Know where every record stands

We needed to track each user record through the stages of the migration, with explicit states and error status. A state-machine approach made the important questions concrete: which stage had a record reached, where had it failed, and what work remained? Status tracking and error logging needed to work together so the team could investigate a specific record and determine how to proceed.

Make the work traceable

The scripts needed a log of their actions, including failures, so that we could reconstruct what had happened when an issue surfaced. In a system involving fund transfers, a retry could not be treated as a blind rerun. Traceability, record state and idempotent behavior were connected requirements: together, they provided the basis for deciding what could be resumed or retried and what needed investigation.

Prepare the destination for production traffic

Moving users was only part of the transition. I also looked at whether the receiving system was ready for the traffic that would follow, including the relationship between performance, scaling and operating cost. Migration throughput and production capacity had to be considered together. A migration plan would be incomplete if it moved the records but left the destination unprepared for the people using the product.

Design for the next partner change

My wider solution-design work focused on keeping a generic platform core maintainable and resilient as integrations changed. Partners can change over the life of a product, so migration capability belongs in the architectural thinking from the outset. Through a CTO’s lens, the practical question is how to support that change while preserving a coherent core and leaving room for future products. That requires balancing the immediate delivery with the cost of maintaining the platform over time.

My contribution and the outcome

I coordinated the technical work across the team, helped resolve critical issues and connected the migration plan with the broader platform design. The team completed the partner migration involving approximately 30k users. The experience reinforced a principle I bring to production change: design the execution so that progress is visible, interruptions are manageable and the destination is ready for the workload it will receive.