Firebase Studio Is Closing: How to Move Your App Without Losing Your Work

You’re still using Firebase Studio to build or maintain an app, and you’ve just discovered that Google is closing it. Your first question is probably whether your website will go offline. Your second is how to keep working on something you’ve already spent months building.

Firebase Studio closes on 22 March 2027. Google says existing Firebase services, including Authentication, Cloud Firestore and App Hosting, will continue running. What you’re losing is the Firebase Studio development environment, including workspace data left there after the deadline. That distinction matters: you may need to move your development workspace without changing your live hosting or database at all.

What exactly is closing, and when?

Google announced the sunset in March 2026. New Firebase Studio workspace creation and new-user sign-up stopped on 22 June 2026. Existing workspaces remain accessible until 22 March 2027, when Google says remaining workspace data will be permanently deleted. These dates are set out in its official migration guide.

An already-deployed Firebase website isn’t automatically being shut down. Google explicitly says core services continue outside Firebase Studio. If your application uses Firebase Authentication, Firestore, Cloud Functions or App Hosting, don’t assume those need moving because the editor is closing.

But don’t mistake a running website for a recoverable development project. Your live service may still work while the code, configuration or prompts you relied on to update it disappear with the old workspace. You need an independent, usable project before the deadline.

First, work out what you actually own

I would start by mapping the application rather than pressing an unfamiliar migration button. Open the current workspace and identify:

• The source-code directory and its Git history, if any.
• Whether the project was generated with Firebase Studio’s app prototyping workflow or imported from an existing repository.
• The Firebase and Google Cloud project IDs used by the deployed app.
• Where user records, customer data, uploads and authentication accounts live.
• Any Cloud Functions, scheduled jobs, API integrations, service accounts and environment variables.
• The current public domain, DNS settings and deployment process.

Record those details separately from the workspace. Don’t publish secret values into a handover document. Record what secrets exist, where they’re configured and who controls them. Make sure the account owner has access independently of whoever originally prompted the app into existence.

Choose a destination that fits how you’ll maintain the app

Google describes two principal migration routes: Google AI Studio for browser-based app building, and Google Antigravity for a more code-first development workflow. It also documents exporting your code if you want to work elsewhere.

That doesn’t mean every Firebase Studio project can simply be opened in another tool and continue unchanged. The right destination depends on what you’ve built.

If you’re using a relatively simple app-prototyping project, investigate Google’s supported export/import path to AI Studio. Confirm that your app’s routes, dependencies and server-side functions are supported before assuming the experience will be identical.

If the project was an imported Git repository or relies on customised server code, a conventional code editor and Git-based deployment may give you more control. Keep the repository under an account you own and document the deployment commands.

If your business depends on the application, choose based on maintainability, security and available technical support, not which new AI tool looks easiest to prompt. You need to know who can patch it and how changes reach production six months from now.

I wouldn’t migrate a functioning database just to follow the development tool. Move services only when there’s a separate technical or commercial reason.

Export the code before doing anything disruptive

Take a dated, independent copy of the current project. Google’s migration guide supports code export or moving the project to an appropriate development environment. Check whether the export includes the files and history you expect rather than treating ‘download complete’ as proof of recovery.

A useful code handover contains the application files, package manifests and lockfiles, build configuration, deployment settings, database schema or migration scripts, and a written inventory of required secrets. Include any custom domains and integration endpoints that the replacement environment needs.

Some generated-project context may not travel automatically. Google notes that agent chat history isn’t included in the normal exported ZIP, and gives a separate procedure for locating it inside the workspace. If past prompts record important implementation decisions, preserve them separately before your access ends.

Then put the code somewhere independent, preferably a private repository controlled by the business. Check that another authorised developer can clone it, install dependencies and start the app without relying on an expiring Firebase Studio session.

A code ZIP is not a working backup of a live application

This is the part people often underestimate. A website can render successfully in a new environment while its login, records, email notifications or payment flows fail.

For a Firebase-backed app, determine whether your code points to the original Firebase project or to a new one. If you retain the original project, data migration may be unnecessary. But you still need to verify access controls, credentials and deployment permissions from the replacement development setup.

If you decide to move backend services, assess Firestore documents and indexes, security rules, Firebase Auth users, Storage objects, scheduled jobs and any integration configuration separately. Authentication migration in particular needs an agreed approach to account continuity and password handling. Don’t copy sensitive production data into an unprotected test environment.

Before any database transfer or schema change, obtain a verified backup and a recovery plan. An export is only useful if you can restore and check it. Don’t overwrite an active production dataset with test records simply because a migration wizard offers to import them.

Test the migrated project without disturbing customers

Once the code works in the destination environment, create a controlled test deployment. Keep the existing production website running while you compare behaviour.

My minimum checks would cover the homepage and deep links, mobile layout, new user registration, existing account login, password reset, forms, uploads, record creation and editing, any payment or webhook flow, and scheduled or server-side actions.

For data-backed features, check that the test application is talking to the intended test database. A test that quietly updates live customer records isn’t a safe test. Equally, a working preview with fake data doesn’t prove that the published app can access production.

Compare the network requests and server logs if a feature works in Firebase Studio but fails after migration. Different environment variables, service identities, allowed origins and deployment settings are more useful clues than repeatedly asking an AI assistant to ‘fix everything’.

Have somebody other than the original builder run through the critical customer journeys. The app should work when they sign in using their own account, not just when the owner is already authenticated in their browser.

Don’t change hosting or DNS until you’ve proved the replacement

If the live app remains on Firebase services, the best initial migration may involve no DNS changes whatsoever. You can move development to a supported tool and leave the public site where it is.

If you also intend to change hosting, prepare a separate cutover plan. Record existing DNS values, TLS certificate arrangements, redirects, server configuration and rollback steps. Know which version is currently serving customers and how you’d return to it if the new deployment fails.

For live databases, consider the cutover window and writes made while you’re moving. You need a clear source of truth. Two independently writable versions of the same application can create conflicting orders, enquiries or customer records.

A successful migration isn’t just seeing the homepage on a new URL. It’s being able to update, deploy, secure, monitor and restore the application without opening Firebase Studio again.

What if the original developer or Google account isn’t available?

Don’t assume access to the website means access to the project. Check who owns the source repository, Firebase project, Cloud billing account, custom domain and any connected API accounts. If they’re owned by different people, deal with permissions before trying to recreate infrastructure.

Google can’t guarantee that undocumented code or a third-party account can be recovered simply because the front end is public. If the original workspace is unavailable, you may need to reconstruct the development project from a repository, deployment artefacts and available configuration. That is a different and potentially larger job than a supported export.

Avoid deleting old workspaces or disconnecting integrations during the investigation. Preserve evidence and access until the new setup has passed testing.

When should you bring in a developer?

If this is a small prototype with no real users or data, Google’s migration tools may be enough. Follow the official instructions, export the code and verify the result.

If it’s taking payments, storing customer information or serving as an operational tool, I would want the dependencies and recovery options documented before anyone starts migrating. The cost of an avoidable account-lockout or data mistake is greater than the effort required to plan it properly.

Firebase Studio’s closure has a definite date. You don’t need to panic, but you do need a working development environment you control well before 22 March 2027. Start with an inventory, preserve the project, move the development workflow, and only migrate live infrastructure if it’s genuinely required.

If you’re unsure how to separate your Firebase Studio workspace from your deployed application, I can assess the project and recommend a safe migration route. That starts with a paid diagnostic to establish what you have, what’s at risk and what needs doing; any migration or repair work is scoped separately.