Field Note · Small business · Japan · 2025 · Case study
Migrating a Live Platform Without Asking Customers to Start Again
A business needed to move an active health platform from its first-generation system to a substantially redesigned second version.
The database structure and many entity fields had changed. The old and new platforms also used different identity services. Thousands of customers were actively using the system, so asking everyone to create a new account or password was not an acceptable migration plan.
The challenge was to move the data and user access safely while keeping the business operating—and to provide a verified way back if the cutover failed.
Design the migration before moving data
We divided the work into four parts: preparation, migration, post-migration verification, and fallback.
During preparation, we compared both MongoDB schemas and created an explicit mapping between old and new fields. We then developed migration scripts to transform and transfer the records.
The scripts were designed to be safely repeatable. Transaction boundaries were used where related changes needed to succeed or fail together, and repeated test runs confirmed that rerunning a step would not create duplicate or inconsistent records.
A migration control record tracked the status of each dataset for validation and possible rollback. After several planning discussions, the client approved a timetable designed around the lowest-impact period for normal operations.
Preserve customer access
The identity transition required particular care because the two platform versions used different authentication and authorization services.
We designed an identity transition that allowed existing customers to access the new system using their established credentials without creating another account or re-entering a password for a new signup. The security-sensitive migration mechanics are deliberately omitted from this public account.
This protected an important part of the customer experience: the upgrade should feel like a platform improvement, not a demand to start over.
Migrate with checks and a way back
Secure database backups were taken before the production migration. The work was divided across team members by dataset, with another person reviewing execution and status.
After the transfer, we verified the migrated records and essential system functions before enabling the new-version configuration. A documented and previously reviewed fallback procedure defined how to restore the earlier state if critical validation failed.
Close the gap left by a live system
The migration required two data movements rather than one.
The initial migration transferred the main body of existing data. However, not every customer installed or opened the new application immediately. During that transition period, new activity could continue in the old system and create a gap between the two databases.
An application-level synchronization process captured those later changes and moved them into the new model. This secondary migration allowed customers to transition at different times without losing the activity created after the initial transfer.
Complete the cutover
The old and new systems continued operating in parallel for a transition period communicated to users in advance. This gave customers time to move to the new version while the synchronization process kept later activity aligned.
At the end of the agreed period, we completed the final validation and migration checks. The old system was then permanently shut down and its allocated infrastructure resources were released, avoiding the ongoing cost and operational risk of maintaining two production environments.
The practical lesson is that a live data migration is not simply a database copy. It is a controlled business transition. Map the change, make the scripts repeatable, preserve customer access, verify the result, synchronize the gap, run a controlled transition period, and retire the old environment only after the new system is proven.