FirebaseStudioIsShuttingDown:GettingYourAppOutBeforeMarch2027

Introduction

Your app works. You described it to an agent, it built the thing, you fixed the parts that were wrong, and now it's live with real people using it. Then you went to open a second workspace and Firebase Studio told you that you can't. That's the moment most people find out.

Google is switching Firebase Studio off. New workspace creation and user signup were disabled on 22 June 2026, and on 22 March 2027 the environment shuts down and everything left inside it is deleted for good. Roughly seven months from today.

Search for what to do about it and you'll find two kinds of answer. Google's migration doc, which is accurate and tells you which button to press. And a stack of posts reassuring you that nothing is really wrong because Firestore keeps running, most of them written by people selling the tool they recommend at the bottom.

Both stop exactly where your real question starts. You don't want to know how to run an export command. You want to know what you're holding once you've run it, and whether it survives contact with the next thousand users. That's what this is about.

Is Firebase Studio really shutting down?

Yes, and the dates are fixed and public. Google's own migration documentation gives three of them. The sunset was announced on 19 March 2026. New workspace creation and user signup were disabled on 22 June 2026. On 22 March 2027 Firebase Studio is shut down and all remaining data is permanently deleted.

Existing workspaces keep working until that last date. You can open them, edit in them, deploy from them. Nothing degrades between now and then. That's the part that makes this dangerous rather than merely annoying, because a deadline with no symptoms until the final day is a deadline teams miss.

Google's stated reason is consolidation. AI Studio becomes the browser-based prototyping environment, and Antigravity becomes the code-first agentic IDE. Firebase Studio sat awkwardly between the two and lost.

None of that helps you. What matters is that the environment your app was built in has a delete date on it, and you're the one holding the app.

What actually happens on 22 March 2027?

The workspace goes, and everything still sitting in it goes with it. Google's wording is unambiguous about the finality here. Remaining data is permanently deleted and it can't be recovered.

Be precise about what a workspace is, because this is where people misread the risk. It's the cloud development environment. Your source tree as it exists in that environment, your editor state, any file you created and never pushed anywhere, and the entire conversation history with the agent.

So the failure mode isn't a dead app. It's a team that still has a running app and no longer has the place it was built, no copy of anything that was never committed, and no record of the reasoning behind any of it.

If your code is already synced to GitHub, you've dodged most of that. If your only copy lives in the workspace, everything below matters a great deal more and you should stop reading and go run the export first.

Does your Firebase backend die with Firebase Studio?

No. Your database is not being deleted, your users are not being logged out, and a deployed app does not go dark. Cloud Firestore, Firebase Authentication and App Hosting all keep running normally outside Firebase Studio, because the sunset applies to the development environment and not to Firebase itself.

It's worth being blunt about this early. A lot of people read the shutdown notice and assume their production data is on a countdown. It isn't. Firebase the backend platform is not going anywhere, and it's the same Firebase that thousands of apps built in a normal editor have been running on for years.

What you're losing is the room, not the furniture. The app keeps serving. The tooling around it, and the history of how it came to exist, is what expires.

That distinction changes what the work actually is. This isn't a data migration, and anyone framing it as one is either confused or selling you something. It's a codebase taking ownership of itself.

What the App Prototyping agent actually built

You can know this exactly rather than guess, which surprises most people. Google documents what the agent produces, and the answer is narrow enough to be useful.

The App Prototyping agent generates Next.js applications. Only Next.js. The documentation says other platforms and frameworks are planned for the future, which in practice means every app it has ever built for you is a Next.js app.

Read that list again and notice what it means. There's no proprietary runtime here, no custom framework, no closed format. It's a Next.js repository talking to Firebase SDKs, which is one of the most ordinary stacks on the web.

That's genuinely good news and it's the reason most of these apps are worth saving. The technical debt in a Firebase Studio app is usually not exotic. It's the same debt any fast-moving team accumulates, just written faster and by something that never asked a clarifying question.

If you want the parallel from a different tool, what Lovable generates covers the same exercise of reading a generated codebase and working out what you actually have.

What does the export actually give you?

Your source tree, through one of three routes. There's a Move now button at the top of the workspace, and a Zip and Download command you can reach from the command palette. There's GitHub sync, which is the one to use if you have any choice. And there's the CLI, npx firebase-tools@latest studio:export, which does the job without spending agent tokens.

One caveat that matters and is easy to miss. That export command is optimised for Next.js, Flutter and Angular workspaces. If your workspace is something else, expect gaps and check the output against the file tree before you close the tab for the last time.

GitHub sync deserves a note of its own. If you were using the App Prototyping agent, it commits its changes to your local branch on every response, which means your repository history is a log of agent turns rather than a log of decisions. Perfectly usable. Just don't expect commit messages to explain anything.

Once the export lands, open three things before anything else. The environment file, to see which Firebase project it points at. The Genkit flow definitions, because that's where the model calls live. And your Firestore security rules, which is the subject we'll get to shortly and the one that tends to matter most.

Why does the export lose the part you most want to keep?

Because the agent conversation doesn't come with it. Google's migration guidance states this plainly. Agent chat history, the trajectories, cannot be migrated, and if there's important logic or prompts in there you need to document it by hand before the shutdown.

Sit with that for a second, because it's the whole problem and almost nobody has named it.

Every constraint you explained to the agent is in that history. Every time you said no, do it this way instead, that's in there. The reason the data model looks strange in one place. The approach that got tried and abandoned. The half of the design that exists in your head and the agent's replies and nowhere in the code.

In a normal codebase that reasoning lives in pull request discussions, commit messages and the memory of whoever wrote it. In this one it lives in a chat log with a delete date on it, and the code that survives will read like it was written by someone who left the company without a handover.

This is the actual loss on 22 March 2027, and it's the one thing on this page you cannot fix later. The code is portable. The intent isn't. If you do one thing after reading this, go back through the agent history and write down why the awkward parts are the way they are, in a file that lives in the repository.

What breaks first when a prototyped app meets real users?

The server-side data path, and it breaks quietly, which is worse than breaking loudly. Here's the mechanism, because it's specific to this stack and it's the thing worth checking tonight.

The Firebase Admin SDK bypasses all security rules. That's by design. It runs with privileged access so backend code can do administrative work. Firestore security rules simply don't apply to it.

Now put that together with a Next.js app doing server-side rendering. If a server component or route handler reaches Firestore through the Admin SDK and hands the result to whoever asked, then every rule you wrote about who can read what has been skipped. The app looks correct in testing, because you're testing as yourself and you're allowed to see your own data. It stays looking correct right up until two users exist and one of them requests the other's record.

This is exactly why Firebase ships FirebaseServerApp, a variant of the JavaScript SDK for server-rendered apps that reads and writes using the requesting user's credentials from the request, so rules still apply. The distinction between those two paths is the difference between a private app and a public one.

An agent asked to make server rendering work will reach for whatever compiles. It isn't weighing your threat model. So the check is mechanical and takes an hour. Find every server-side Firestore call, decide for each one whether it's genuinely administrative, and move the rest onto a credentialed path.

The same class of problem shows up in every tool in this category, which is why vibe coding security keeps circling the data layer rather than the UI.

Do the security rules an agent wrote hold up?

Assume not until you've tested them, and take that from Google rather than from us. The App Prototyping agent documentation carries the warning directly. Gemini can generate output that seems plausible but is factually incorrect, and you should not use untested generated code in production.

The vendor put that in writing. Not one of the migration guides currently ranking for this topic repeats it.

Security rules are the worst possible place for plausible-but-wrong code, because a wrong rule fails open and stays silent. There's no error, no log line, no failed request. Data is simply readable by people who shouldn't be reading it, and you find out when somebody tells you.

Test them properly with the Firestore emulator and a rules test suite, with at least two fake users, then try to read across the boundary between them. If the read succeeds, you've found a real one. If your app holds anything personal, this stops being a code quality question and becomes a compliance question.

Is Google AI Studio or Antigravity the right destination?

Antigravity, if you intend to keep the app. It's a local, code-first IDE with agents built into it, it deploys to Firebase, it runs the Firebase CLI and local emulators, and it needs Node.js 20 or above with Firebase CLI 15.10.0 or above. The migration path is documented and it's short. Export, open locally, preview, publish.

Google AI Studio is the other suggestion and it's the one to think about carefully. It's a prototyping environment, and it's a good one. But moving a live product out of a prototyping tool that's being switched off and into a different hosted prototyping tool is how you end up doing this again, on somebody else's timetable.

That's not a prediction about AI Studio's future. It's a point about where your code should live. Code with users on it belongs in a repository you control, running on infrastructure you hold the credentials to. Anything else is a bet that a product roadmap stays convenient for you.

The third row is the one we'd argue for in most cases, and Antigravity is a perfectly good editor to do that work in. The two aren't in conflict. What matters is that the repository is yours and the deployment path doesn't depend on a product staying alive.

Who should just move this themselves?

Plenty of people, and we'd rather say so than pretend otherwise.

If your app is a prototype, has no real users, takes no payments and stores nothing personal, this is an afternoon of work and you don't need help with it. Run the export, push it to a repository, open it in Antigravity or whatever editor you like, confirm it builds and runs, and you're finished. Write down what the agent history says while you still can.

The same goes if you have engineers. A competent Next.js developer will read a generated codebase faster than they'd read a description of one. The security check described above is a known procedure, not a specialism.

Where it stops being a weekend job is when several of these are true at once. Real users are on it. Money moves through it. It holds health, financial or identity data. Nobody currently on the team wrote it or can explain it. Or it's already slow and you don't know why.

That's a different exercise, because then you're not moving a repository. You're taking ownership of a system nobody has read, on a deadline, while it's serving traffic.

When is a rebuild the wrong answer?

Most of the time, and we'll be direct about why you should be suspicious when you hear otherwise.

Every founder walking into an agency with a generated app is braced to be told to throw it away and start over. It's a reasonable thing to expect, because a rebuild bills more and takes longer and the incentive is obvious to everyone in the room.

The honest technical answer is that a Firebase Studio app is unusually salvageable. It's Next.js. It's the Firebase SDKs. There's no proprietary runtime to escape, no closed data format, no vendor to negotiate with. The framework is one the entire industry knows.

What usually needs real work is narrower than a rebuild. The data layer, where an agent modelled collections to make a screen work rather than to make queries efficient. The server-side access path from earlier. The Genkit flows, where a model call without a limit on it is the single fastest way to turn a good month into a bad invoice. And test coverage, which generated apps almost never have.

Fix those four and you generally have a product worth keeping. A rebuild earns its place when the data model is wrong in a way that can't be migrated around, or when the app's actual requirements have moved so far from what was prototyped that you'd be rewriting it anyway. That's a real situation. It's just far less common than it gets diagnosed.

Teams working through the same decision on other platforms can read Base44 to production and Lovable to production, which cover the port-or-rebuild call in more detail.

The four-stage way out

This is the order we'd work in, and the order matters because each stage makes the next one safe.

Stage two is the one people skip, and it's the one they regret. The code will still be exportable in February. The chat log will not.

If Firestore itself turns out to be a poor fit once you can see the data model clearly, that's a separate decision and a later one. Supabase versus Firebase covers that ground, and Supabase production scaling covers what the other side actually looks like. Don't bundle it into this migration. One risky change at a time.

How long does getting out actually take?

It depends on things anyone can count before starting, and anyone who answers without seeing the export is guessing.

The first stage, getting the code out and running locally, is usually quick for everyone. It's stages two and three that separate a straightforward week from a long month, and the deciding factor is almost always how much was built and never explained.

The one honest thing to say about scheduling is that seven months sounds like a lot and isn't, because the work that has the real deadline on it is the documentation work, and documentation work is what teams postpone.

Where this leaves you

Better placed than the shutdown notice makes it feel, as long as you move before March.

Your app keeps running. Your data is safe. What you built is a Next.js application on Firebase, which is an ordinary, well understood, entirely portable stack. That's a much better position than most people leaving a hosted builder end up in, and it's worth saying clearly because the panic around this is out of proportion to the technical reality.

The two things that genuinely need doing are the ones nobody else is telling you about. Recover the reasoning out of the agent history before 22 March 2027, because that's the only part of this that can't be recovered afterwards. And check the server-side data path, because that's the failure that stays invisible until it isn't.

Geminate Solutions has shipped 50+ products, and every one of them belongs to the client, code and credentials included. We're a product development partner, not a staffing marketplace. If you want a second pair of eyes on a Firebase Studio export, send it over and a senior engineer will read the actual code and tell you what's genuinely broken, what's fine, and what can wait. Free, and if the answer is that you can handle this yourself, that's what you'll be told.