Firebase Studio Shutdown: Timeline and Migration Guide
Last fact-checked: July 2026.
Firebase Studio shuts down on March 22, 2027. Learn the timeline, backup steps, migration options and alternatives for existing workspaces.
Google is sunsetting Firebase Studio, its browser-based, AI-assisted development environment. Existing users have a transition period, but waiting until the final week is a bad backup plan. Export every workspace, verify that the export opens elsewhere, document its connected Firebase project, and move active development to Google AI Studio, Google Antigravity, or another development environment before March 22, 2027.
This change does not mean that Firebase itself is shutting down. Cloud Firestore, Firebase Authentication, App Hosting, and other core Firebase services continue to operate outside Firebase Studio. An app already deployed to Firebase does not stop merely because its development workspace moves.
The corrected timeline
- March 19, 2026: Google announced the sunset and began rolling out migration tools.
- June 22, 2026: new Firebase Studio workspace creation and new-user signup were disabled. Existing users can still work in and migrate existing workspaces.
- March 22, 2027: Firebase Studio shuts down. Google says remaining data will be permanently deleted and cannot be recovered.
Google's official sunset and migration page is the source of truth for these dates and may receive procedural updates. Check it again immediately before migrating a production application.
Firebase Studio and Firebase are different things
The previous version of this article described Firebase Studio as a Backend as a Service (BaaS) and compared it with Supabase, AWS Amplify, and Back4App. That comparison mixed two categories.
Firebase Studio is the development environment that provided browser workspaces, code editing, previews, templates, an App Prototyping agent, and Gemini assistance. It was where a developer worked on application source code.
Firebase is the broader application platform. Its services include Cloud Firestore, Authentication, Cloud Storage, Hosting, App Hosting, Cloud Functions integrations, analytics products, and more. An application can use those services whether its code is written in Firebase Studio, a local IDE, Google AI Studio, Antigravity, or another editor.
Moving the source code and development workflow does not automatically move or delete the backend. It also does not remove billing, security rules, deployed services, stored data, authorized domains, environment variables, or API keys. Those resources must be inventoried separately in the Firebase and Google Cloud consoles.
Do these backup steps before choosing a destination
- List every workspace and owner. Shared workspaces need special attention because only the creator can use the Move now button. A collaborator can manually export code, but the copied configuration may still point to the original owner's Firebase resources.
- Record the connected Firebase project. Save the project ID, App Hosting backend name, deployed URL, custom domains, Authentication providers, authorized domains, database locations, and billing owner.
- Export the source. In Firebase Studio, choose Move now > Zip and Download. If that interface is unavailable, open the command palette and run Firebase Studio: Zip & Download. Extract the archive locally.
- Keep a second copy. Store the archive in a separate backed-up location. A GitHub export is useful for version history, but it should not be the only backup.
- Protect secrets. Review
.envand other configuration files. Do not commit API keys, service-account keys, private certificates, or production secrets to GitHub. If a secret was exposed, rotate it rather than merely deleting the file from the latest commit. - Save useful AI history separately. Google says agent chat history is not included in the current exported zip. Its migration FAQ explains how to download the
/home/user/.idx/aidirectory if those prompts and responses matter. - Test the copy. Install dependencies from the lockfile, run the app in a clean environment, and check authentication, database access, uploads, server-side functions, and deployment. An archive that has never been opened is not a verified backup.
Option 1: migrate to Google AI Studio
Google recommends Google AI Studio for rapid, prompt-based, browser development. It is the closer destination for people who used Firebase Studio's App Prototyping agent and want to keep a web-based workflow. Google has integrated Cloud Firestore and Firebase Authentication into this path.
From the Firebase Studio workspace, select Move now, choose Prepare for AI Studio, wait for preparation to finish, and then choose Move to Google AI Studio. Review any terms presented. The code should open in a new AI Studio workspace after conversion. Test it before treating the migration as complete.
Publishing from Google AI Studio
If an app already uses Firebase App Hosting and must keep its *.hosted.app URL or custom domain, Google's documented route uses GitHub sync and reconnects the repository to the existing App Hosting backend. Review the staged files and confirm that .env is excluded. Store required environment variables in the App Hosting environment settings or use Secret Manager when you need more granular controls.
If keeping the current URL is unnecessary, AI Studio can publish to Cloud Run and produce a new *.run.app URL. A custom domain must then be mapped to the new service, which may introduce downtime. Choose the publishing route deliberately; moving the editor and moving production hosting are separate decisions.
Google also says an AI Studio app can later be exported to Antigravity from its Code tab. That makes AI Studio a reasonable first stop for a prototype that may become a larger code-first project.
Option 2: migrate to Google Antigravity
Google recommends Google Antigravity for code-first development, local execution, terminal access, and agent-oriented workflows. It fits projects created from a built-in template or imported repository, projects primarily developed in Code View, and prototypes that have grown beyond a browser sandbox.
The official automated path requires the current Antigravity IDE, Node.js 20 or later, and Firebase CLI 15.10.0 or later. Export the Firebase Studio workspace as a zip, extract it, open it in the Antigravity IDE, and follow Google's current migration procedure. Do not accept an agent's changes blindly: inspect the diff, run the tests, and verify the generated deployment configuration.
Antigravity can publish to an existing Firebase App Hosting URL when the project is linked correctly. Confirm the selected Firebase project and backend before approving a deployment. A mistaken project selection can send test code to production.
Option 3: move to another IDE or hosting platform
The exported source is a normal web project, so Google does not require you to use either successor. You can open it in VS Code, another local IDE, a cloud development environment, or your organization's existing toolchain. Import the code into a private repository, recreate the development environment from documented versions, and configure secrets through the destination's secret store.
To keep an existing Firebase App Hosting URL while deploying from a local environment, Google's migration page describes using the Firebase CLI, running firebase init apphosting, linking the existing backend (often named studio), and deploying with firebase deploy. Read the generated firebase.json and review the target shown by the CLI before deployment.
You may also move hosting to another provider. That normally produces a new URL and may require DNS changes, environment-variable migration, build-command changes, and a rollback plan. Core Firebase services can remain the backend if the application is configured and authorized correctly. For local-only work, the Firebase Local Emulator Suite can support development and testing without deploying every change.
What continues after Firebase Studio closes
- Apps already deployed to Firebase continue to run, subject to their normal configuration, billing, quotas, and service status.
- Cloud Firestore, Firebase Authentication, App Hosting, and other core Firebase products are not part of the Firebase Studio sunset.
- Your Firebase project, production data, security rules, and users do not move simply because source code was exported.
- Firebase Studio workspace data that remains on March 22, 2027 is scheduled for permanent deletion.
Post-migration verification checklist
- The source exists locally and in a backed-up repository.
- A clean checkout installs and builds using documented runtime versions.
.env, service-account files, and other secrets are absent from Git history.- The development, staging, and production Firebase project IDs are correct.
- Authentication providers work, including Google Sign-In. Add the new app domain under Firebase Authentication's authorized domains when required.
- Firestore and Storage security rules still enforce the intended access.
- App Hosting or Cloud Run deploys from the new workflow, and the correct URL serves the tested revision.
- Custom domains, DNS, monitoring, logs, budgets, and alerts have been checked.
- The team knows where the new repository, secrets, deployment instructions, and rollback procedure live.
A practical migration schedule
Migrate active production projects first, then prototypes worth keeping, then archive abandoned experiments. Finish well before March 2027 so there is time to discover missing files, owner-access problems, or deployment differences. Keep the original workspace unchanged until the replacement builds and deploys successfully, but do not rely on it as the only copy.
Firebase Studio's closure is a development-tool migration, not the end of Firebase. Treat the source workspace, deployed hosting, and backend services as three separate layers. Back up each layer that contains irreplaceable information, test the new workflow, and only then retire the old one.
Primary source: Firebase Studio sunset and project migration. For product-specific support, use Firebase Support.
Comments