The owner of a live SaaS rarely gets to choose a quiet month for a replatform. Customers log in every day, pay every month, and expect the next update on schedule. A zero downtime database migration moves their accounts to a new system while all of that keeps happening.
The buyers we talk to already know the shape of the plan. A Communications and Creative Services Manager at a US residential community described hers on a discovery call: "My plan is to … run this website … concurrently while we build and then switch."
That plan is sound. The hard part sits inside the word "switch". Below is how we handle it, with the CondoGenie migration as the worked example: the sequence of runs, the fixes between them, and the framework and payment upgrades that followed on the same live platform.
TL;DR
- A zero downtime database migration moves data in small, repeatable runs while the old system keeps serving customers.
- Each run surfaces mismatches. You fix them and run again, and feature releases continue in between.
- We moved 9 years of GeniePad accounts, documents, and user histories into CondoGenie this way, without taking the platform offline.
- The same discipline carried a Rails upgrade (no customer-facing downtime) and a Stripe API migration against live subscriptions.
What zero downtime database migration means for a live SaaS
Zero downtime database migration means your customers keep logging in, paying, and receiving updates while their data moves from the old system to the new one. Nobody sees a maintenance page, and nobody loses a record.
For a database administrator, the term often means a schema change on one database without locking tables. For the owner of a SaaS product, the stakes are commercial. The migration is one part of a decision to leave a stack that holds the product back: the platform can no longer scale with the customer base, or each new feature takes months because the old code resists change, and competitors ship first.
This article covers the SaaS owner's case: a live product moves onto a new platform, with years of customer accounts, documents, and histories, while customers keep using it. The 2 systems rarely share a data model, so the data has to be mapped and moved with care. That move is one step in a wider plan to modernize without stopping the business, and it usually carries the most risk of any step in that plan.
The working rule: the old system stays the source of truth until the new one has proven, run after run, that it holds the same data. Until then, every customer action still lands in the old system, and the new one only receives copies you can check.
Why the user data is the part you cannot lose
Saying that user data matters sounds obvious. It still needs spelling out, because the data sets the scope of every run that follows.
A team can rewrite code and redesign screens on its own schedule. Rebuilding customer history after a migration loses part of it is slow and expensive, and every affected customer notices.
The Communications and Creative Services Manager quoted above named her priority when the talk turned to what had to move to the new platform: "At least the user data, because I own that."
In a property management SaaS, user data means specific records: each resident's documents, and the invoice and payment history behind every account balance. Product owners accept a new interface and a new stack. They expect every one of those records on the other side.
So the migration plan starts from the data and works outward:
- Which records the business owns and must carry over: accounts, roles, documents, payment history
- Which content needs an audit first
- Who can export the data today, in what format, and how often
Any record type left off this list tends to surface as a gap after the switch.
Move the data run by run, alongside feature work
A run-by-run migration carries less risk than a big-bang cutover, which moves all the data at once, usually over a weekend. Moving the data in small batches and checking each one means a mapping error shows up in one slice of accounts, while customers still work in the old system.
Here is the sequence we in Brocoders follow:
- Map the schemas. Match every table and field in the old system to its place in the new one, and list the records that have no obvious home.
- Run a batch. Move a slice of real accounts into the new system, with the old system still live.
- Compare. Check counts, relationships, and documents between the 2 systems for that slice.
- Fix and restore. Repair every mismatch in the mapping or the data, and restore anything that failed to carry over.
- Run again. Repeat with the next slice, and with the earlier slices, until runs come back clean.
- Switch. Move users over once the new system has held clean data across repeated runs.
The compare step does most of the work. A count that matches can still hide a document attached to the wrong account, so the check covers relationships as well as totals.
Feature work keeps going while this happens. The migration runs on its own track, and product releases go out on their usual calendar.
The same thinking applies to code. The strangler fig pattern replaces a legacy application piece by piece, and a run-by-run migration does the same for data.
How CondoGenie moved 9 years of accounts while the business kept running
CondoGenie is a condominium management SaaS. Its predecessor, GeniePad, dates from 2009 and was built for a single building. When we started working with its founder, Rafal, in 2018, he wanted to sell a multi-tenant, self-serve product, and GeniePad could not support one.
After a requirements phase with a business analyst, we recommended a rebuild over extending GeniePad: a new multi-tenant codebase with a new name and a new interface. Product logic, user accounts, documents, histories, and customers all had to carry over.
Migrating GeniePad's existing user data was the highest-risk part of that engagement. It ran alongside feature development, in the same months as the releases.
The early runs surfaced schema mismatches and records that did not map cleanly. That is the normal result of moving data out of a system that had accumulated 9 years of exceptions.
We fixed or restored every one, under the release timelines the business needed to keep. We repaired mismatches run by run and never took the platform offline.
The fix cycle got shorter for 2 reasons:
- End users reported problems directly to the team. Rafal's customers told us what they spotted, which shortened the path from a broken record to a fix.
- The founder held the go or no-go. Rafal reviews staging and gives go or no-go, so a change reaches production only with his sign-off.
The result: 9 years of accounts, documents, and user histories now live in CondoGenie, and the business ran without a pause while they moved. We have delivered on the product continuously since, 8 years from 2018 to 2026.
Upgrade the framework and the payment API with customers online
A data migration is the largest move, and it rarely stays the only one. A live product also needs its framework and its integrations kept current, and each of those upgrades carries the same risk to paying customers.
On CondoGenie, 3 of them ran against a live paying customer base:
- Ruby on Rails upgrade. Scoped in June 2025 and released on Aug. 15, 2025, with no customer-facing downtime. Feature work continued in parallel.
- Test suite moved to Playwright. From June to September 2025.
- Stripe API version migration. In February 2026, against live subscriptions.
A pair of safety nets makes this repeatable. Automated tests catch regressions before a release, and Sentry runs in production, so defects surface to the team before they reach Rafal or his customers.
This is the everyday side of application modernization: many small upgrades on a running product, each one released on the normal calendar.
A checklist before your first migration run
Before the first batch moves, a product owner can settle most of the risk with a short list of decisions:
- Data ownership. Confirm you can export your user data in full, and in what format.
- Scope. List what must move (accounts, roles, documents, payments) and what needs an audit first.
- Parallel run. Decide how long the old and new systems run side by side, and what "clean" means before you switch.
- Rollback. Agree which result stops a run and returns users to the old system, before anyone needs to make that call.
- Sign-off. Name the person who reviews staging and gives go or no-go.
- Issue reporting. Decide who reports problems after each run and how they reach the engineers.
- Monitoring. Put error tracking in production before the first user moves.
- Release calendar. Keep feature releases on schedule so the migration never becomes the only thing customers notice.
If you run a live SaaS, here in Brocoders we start a migration plan from your data and your release calendar, and we have done it for property management SaaS products like CondoGenie. Talk to us about application modernization.
FAQ
It is a move of data from one system to another while customers keep using the product. The data moves in repeatable runs, each one checked and fixed, and users switch only once the new system holds clean data.
Yes. We moved 9 years of GeniePad accounts, documents, and user histories into CondoGenie while the business kept running, and later upgraded Rails and the Stripe API on the same live platform.
Long enough for consecutive runs to come back clean on real data. The length depends on data volume and on how many exceptions the old system holds, so set the exit criteria first and let them decide the date.
Keep the old system as the source of truth until the switch. A failed run then costs you a rerun: you fix the mapping, restore the affected records, and run that slice again, while customers stay on the system they already use.
They move with the product. Their accounts, documents, and histories carry over in runs, and they keep using the old system until the new one is ready for them.