Firebase is a wonderful way to start. It is a difficult place to grow up. The same things that make it fast on day one, schemaless documents, a closed auth system, queries that hide their cost, become the things that fight you once the product gets complicated and the data gets relational.

We rebuilt a fundraising platform that had outgrown it. The new foundation was PostgreSQL with Prisma for the data and a modern auth library for accounts. The constraint that made it interesting was simple. The old app had real users who could not be logged out, and real records that could not be lost. The ground had to move while people were standing on it.

You are not migrating data, you are migrating trust

It is easy to frame a migration as moving rows from A to B. The rows are the easy part. The hard part is that every user has an account, a password, a session, and an expectation that none of it will break. Lose a record and you have a bug. Log everyone out, or worse, lock someone out, and you have lost their trust on a platform that runs on it.

So we treated accounts as the highest-risk part of the move, not an afterthought. The plan had to let an existing user sign in with their existing credentials on the new system, with no reset email, no friction, no sign that anything had changed underneath them.

Moving the data is a script. Moving the accounts without anyone noticing is the actual project.

Carry the old identity forward

The technique that makes this work is to keep a thread back to the old world on every record. As we brought data across, each migrated row remembered its original identifier from the old system. That mapping is what lets the new app recognize an old user and reconcile the two worlds without guessing.

Authentication gets the same treatment. We flag which accounts were carried over from the legacy system and handle their first sign-in specially, validating against the old credentials and quietly upgrading them into the new scheme. The user types the same password they always have. They never learn that the machinery behind it was replaced.

Migrate in phases, never in one leap

A big-bang cutover, where you flip everything at midnight and pray, is how migrations become outages. We avoid it. The model that works is to run the new system alongside the old, move data in controlled passes, and keep the ability to verify each pass before trusting it.

That means writing migrations that are safe to run more than once, so a half-finished pass can be repeated without creating duplicates. It means checking counts and spot-checking records after every stage. And it means keeping the old system readable until the new one has earned the traffic, so there is always a place to look when a number does not match.

Schema is a feature, not a tax

The deeper payoff of the move was the schema itself. Firestore lets you store anything, which feels like freedom until you realize nobody can say what shape the data is actually in. Moving to a real relational schema forced the questions that had been deferred for years. What is required, what relates to what, what must never happen.

That work is not overhead, it is where a lot of latent bugs go to die. A schema you can read out loud is a schema your whole team can reason about. The constraints the database now enforces are rules you no longer have to remember to enforce by hand.

The boring goal is the right goal

The success metric for a migration like this is that nobody noticed. No support tickets about lost data, no wave of password resets, no mysterious gaps in the records. Boring is the win. You get there by treating accounts as sacred, carrying the old identity forward, moving in verifiable phases, and using the new schema to pay down debt you had been carrying for years. Do it well and the only evidence it happened is that everything suddenly got easier to build.