Firebase Extensions Is Shutting Down: How to Migrate Before March 31, 2027

Firebase Extensions is officially deprecated and will shut down on March 31, 2027. Existing deployed extension resources do not simply disappear on that date, but the managed Extensions layer does: after shutdown, Firebase says you will no longer be able to update, reconfigure or uninstall installed extensions through the Firebase console or CLI.

That makes the correct response neither “panic and rewrite everything” nor “do nothing because the functions keep running”. The practical path is to inventory every installed extension, update active instances now, remove unused ones before shutdown, identify the Google Cloud resources and runtimes each extension depends on, and migrate active workloads to self-managed Cloud Functions when Firebase's migration path is available.

This guide explains what actually changes, which risks remain if you do nothing, and how to prepare a controlled migration without breaking production workflows.

What exactly is being shut down?

Google's current Firebase Extensions Deprecation FAQ says the managed Firebase Extensions service will shut down on March 31, 2027.

The important distinction is between the Extensions management layer and the Google Cloud resources an extension already deployed.

An installed extension can create or use resources such as:

• Cloud Functions
• Eventarc triggers
• Cloud Run resources
• Cloud Tasks queues
• Secret Manager secrets
• IAM service accounts and roles
• scheduled or event-driven infrastructure

Firebase says already-deployed extension resources will continue to execute after the Extensions shutdown because they run on standard Google Cloud infrastructure.

But after March 31, 2027, the Extensions console/CLI management experience will no longer let you:

• update an installed extension
• change extension parameters or environment configuration
• apply extension bug fixes and dependency upgrades
• uninstall the extension through the normal Extensions workflow

If you later need to remove an abandoned installation, Firebase says the associated Google Cloud resources will need to be deleted manually.

So the real shutdown model is:

Before March 31, 2027
Firebase Extension
→ managed configuration
→ managed update/reconfigure/uninstall
→ underlying Google Cloud resources

After March 31, 2027
underlying Google Cloud resources may keep running
→ but Firebase Extensions management is gone
→ future maintenance becomes your responsibility

That is why “the functions keep running” is not a complete migration strategy.

What happens if you do nothing?

Your installed extension may continue executing after March 31, 2027, but it becomes progressively harder and riskier to maintain.

Firebase identifies three important consequences of doing nothing:

1. configuration parameters and environment values can no longer be changed through the Extensions workflow
2. extension fixes, security updates and dependency upgrades can no longer be applied through normal extension updates
3. many extensions still rely on Cloud Functions 1st gen and older Node.js runtimes, so underlying runtime retirement can eventually stop or disable those functions

The third point is easy to underestimate.

Google Cloud's current runtime support table shows that language runtimes have their own deprecation and decommission schedules. For example, Node.js 20 is listed for decommissioning on October 30, 2026, while Node.js 22 is currently listed through October 31, 2027.

That does not mean every installed Firebase extension uses Node.js 20. It means you need to inspect the actual functions created by your extensions rather than assuming “deployed indefinitely” means “supported indefinitely”.

A useful risk model is:

Extension keeps executing
        ↓
Can we still patch it?
        ↓
Can we change configuration?
        ↓
Is its runtime still supported?
        ↓
Are dependencies still maintained?
        ↓
Can we remove or replace it safely?

If the answer to any of those questions is unclear, the extension belongs in your migration inventory.

Is Firebase Extensions being replaced?

Firebase says installed extensions will migrate toward self-managed Cloud Functions with similar behaviour.

As of September 5, 2026, Firebase's user-facing FAQ says comprehensive user migration documentation and tooling will be released during September 2026. The detailed public migration guide already available today is primarily for extension publishers, not ordinary extension users.

For publishers, Google's recommended direction is clear: package the extension logic as code that users deploy into their own Cloud Functions for Firebase 2nd gen codebase. The current publisher migration guide describes this as the recommended path and says Firebase will maintain a list of extensions with official npm equivalents.

The model changes from:

Install managed Firebase Extension
        ↓
Firebase owns extension lifecycle/config UI

to:

Install/import function package
        ↓
Your Cloud Functions codebase
        ↓
Your deployment, config, secrets and lifecycle

This gives app teams more control, but it also transfers more maintenance responsibility to the application repository.

Should existing extension users migrate immediately?

Inventory immediately. Migrate deliberately.

For an ordinary Firebase project using third-party or official extensions, there is little value in blindly reverse-engineering every installation before Firebase publishes the full user migration tooling.

A sensible September 2026 decision tree is:

The key is to separate discovery from cutover.

You can do the discovery safely now without changing production behaviour.

Step 1: inventory every installed extension

Firebase's current CLI reference includes commands specifically useful for this audit.

List all installed extension instances:

firebase ext:list --project YOUR_PROJECT_ID

Export installed extension definitions into your project manifest:

firebase ext:export --project YOUR_PROJECT_ID

For each instance, record at least:

Do not rely only on the Extensions dashboard. The migration target is the behaviour and resources the extension created.

Step 2: update extensions you still depend on

Firebase's current deprecation guidance explicitly recommends keeping actively used extensions on their latest available versions while the service is still operational.

That matters because an updated version may include:

• dependency upgrades
• runtime upgrades
• security fixes
• migration compatibility
• publisher changes required for the future function-package model

The worst time to discover that an extension is multiple major versions behind is after its managed update path has disappeared.

Before updating production, review the extension's release notes and test the update in an appropriate non-production project when the workflow is business-critical.

Step 3: uninstall extensions you no longer use

Unused extensions are migration debt with no business value.

Firebase says the normal Extensions uninstall workflow disappears after March 31, 2027. After that, removal may require manually cleaning up resources such as Cloud Functions, Secret Manager secrets, Cloud Tasks queues and custom IAM service accounts.

So if an extension is genuinely unused:

Confirm no dependent workflow
→ back up any needed data/config
→ uninstall through Firebase now
→ verify generated resources are removed as expected

Do not wait until shutdown merely because the current deployment is harmless.

Step 4: map extension instances to actual Cloud Functions and resources

Firebase's extension management documentation notes that extension-created functions normally use names beginning with the extension instance prefix, for example:

ext-INSTANCE_ID-functionName

Use that mapping to inspect:

• function generation
• runtime version
• region
• trigger type
• environment/config values
• service account
• IAM permissions
• logs and invocation volume
• dependent queues or schedulers

This turns an abstract extension into an operational dependency graph.

For example:

Trigger Email extension
        ↓
Firestore document trigger
        ↓
Cloud Function
        ↓
SMTP secret
        ↓
mail provider
        ↓
delivery status written back to Firestore

A replacement is not complete merely because “the function deploys”. It must preserve the full business workflow.

Step 5: check runtime risk, especially for 1st gen functions

Firebase warns that many existing extensions are based on the legacy Cloud Functions 1st gen SDK and older Node.js runtimes.

For each generated function, record:

1st gen or 2nd gen?
Node/Python runtime?
Runtime deprecation date?
Runtime decommission date?
Extension update available?
Publisher migration path available?

Do not assume the shutdown date is your only deadline.

A runtime can become the earlier constraint.

This is particularly important for extensions that process payments, email, image transformations, backups, search indexes or production data pipelines. A silent runtime retirement can become a customer-facing incident.

Step 6: preserve configuration and secrets without copying them into source control

Managed extensions often collect parameters during installation and bind secrets behind the scenes.

In the self-managed model, these values need an explicit home.

Firebase's publisher migration guidance maps extension configuration toward Cloud Functions parameter APIs and secrets. It also warns publishers to preserve parameter and secret names so migration tooling can carry user values across correctly.

For your own migration design, classify settings as:

Non-secret config
→ Cloud Functions params / environment configuration

Secrets
→ Secret Manager / Firebase Functions secret binding

Derived runtime state
→ recreate or migrate deliberately

Never solve the migration by pasting SMTP passwords, API keys or private tokens into __INLINE_CODE_0__.

Step 7: choose the migration path per extension

There is no single migration path for every installed extension.

Path A: official publisher replacement

Prefer the publisher-supported function package or migration tool when it exists.

Benefits:

• behaviour is more likely to match the original extension
• configuration migration may be supported
• upstream fixes can continue
• you avoid forking code unnecessarily

Path B: self-managed reimplementation

Choose this when the original extension is abandoned, overly generic or no longer fits the application.

The target can be a small set of normal 2nd gen functions that implement only the behaviour you need.

This often reduces hidden infrastructure, but your team owns the code thereafter.

Path C: replace with a managed product/API

Sometimes the right migration is not another function.

For example, an extension wrapping an external email/search/payment service may be better replaced by a maintained vendor SDK or a deliberately designed integration service.

Evaluate:

• failure handling
• retries
• idempotency
• observability
• security
• data residency
• cost
• vendor lock-in

Path D: remove the feature

If nobody can explain why the extension exists, migration may be the wrong project.

Remove it safely instead.

What changes for extension publishers?

Publishers have more work because they need to provide the migration destination.

Firebase's current publisher guide recommends converting extension code into an installable package for Cloud Functions for Firebase 2nd gen.

As of September 2026, the guide specifies minimum package expectations including:

• __INLINE_CODE_0__ 7.3 or newer
• __INLINE_CODE_0__ 14.2 or newer
• Node.js 22 or newer in the package example
• __INLINE_CODE_0__ also declared as a peer dependency
• conversion of 1st gen triggers to 2nd gen equivalents
• parameters moved from __INLINE_CODE_0__ into Cloud Functions parameter declarations
• secrets explicitly declared and bound
• IAM roles and required APIs declared in code
• lifecycle setup moved to Cloud Functions lifecycle hooks

Firebase also notes a current limitation: Authentication triggers are not yet supported in 2nd gen for this migration path, so publishers using those triggers cannot complete that part of the function-kit transition yet.

That is exactly why ordinary users should prefer a publisher-supported migration rather than guessing at the internals.

Why 2nd gen is the migration target

Firebase's publisher guidance explicitly recommends 2nd gen Cloud Functions for migrated extension packages.

The architectural shift is useful beyond the deprecation itself:

Managed opaque-ish extension lifecycle
        ↓
Normal application codebase
        ↓
Version control
        ↓
Code review
        ↓
Environment-specific configuration
        ↓
Normal Firebase deploy pipeline
        ↓
Standard logs/testing/ownership

The trade-off is ownership.

With a managed extension, much of the packaging and configuration lifecycle was provided for you. With self-managed functions, your engineering team is responsible for upgrades, dependency maintenance and operational correctness.

How should a Flutter or mobile app team think about this?

The mobile client may not need any code changes at all.

Many Firebase Extensions sit entirely behind Firestore, Storage, Authentication or backend events.

For a Flutter application, the migration may look like:

Flutter app
   ↓
Firestore / Storage / Auth
   ↓
existing Firebase Extension

becoming:

Flutter app
   ↓
Firestore / Storage / Auth
   ↓
self-managed Cloud Function

If the input/output contract remains the same, the app can remain unchanged.

But you need to verify contract details such as:

• Firestore collection/document paths
• status fields written by the function
• Storage object naming
• callable/HTTP endpoint URLs
• custom event names
• error states
• retries
• latency assumptions

Treat the migration as a backend contract migration, not automatically a mobile rewrite.

How do you migrate without double-processing production events?

This is one of the most important cutover risks.

If the old extension and new function listen to the same Firestore, Storage or Eventarc trigger at the same time, both may process the same event.

For side effects such as:

• sending email
• charging or refunding payments
• resizing images
• exporting data
• updating search indexes
• issuing notifications

that can be damaging.

A safer cutover plan is:

1. Deploy replacement in non-production
2. Verify behaviour against representative events
3. Add idempotency where side effects matter
4. Decide how production cutover disables one consumer before enabling the other
5. Observe logs/metrics during cutover
6. Keep a rollback path
7. Remove old resources only after stability is proven

Do not run two trigger consumers in parallel unless the workflow is explicitly designed for duplicate delivery.

How should you verify a migrated extension?

Do not stop at “deployment succeeded”.

Build a behaviour checklist from the original extension.

For each trigger, verify:

• the same event fires the replacement
• the same input data is accepted
• outputs are written to the expected location
• secrets are available
• IAM permissions are sufficient but not broader than needed
• retries behave correctly
• duplicate events do not duplicate irreversible side effects
• logs contain useful identifiers
• failure paths are observable
• billing/usage remains acceptable

For data pipelines, reconcile record counts or sample outputs between the old and new paths.

For customer-facing workflows, test the entire user journey rather than only the Cloud Function.

A practical migration sequence

Phase 1: inventory now

Run __INLINE_CODE_0__, export the manifest, map generated resources, and identify owners.

Phase 2: reduce the estate

Uninstall unused extensions and update active ones while the management service is still available.

Phase 3: classify risk

Rank each active extension by:

business criticality
×
runtime/dependency age
×
publisher support
×
data/side-effect risk

A production payment or email workflow deserves attention before a low-volume utility.

Phase 4: wait for or adopt the supported migration path

For normal extension users, use Firebase's September migration tooling when available for the specific extension.

For custom publishers or owned extension source, begin the documented 2nd gen conversion now.

Phase 5: test replacement behaviour

Use a test Firebase project and representative data/events.

Phase 6: perform a controlled production cutover

Prevent duplicate event consumers, observe logs and metrics, and keep rollback options.

Phase 7: remove managed-extension dependencies

Once stable, confirm the application no longer depends on the Extensions management layer and document the new ownership model.

Migration checklist

• □Every Firebase project has been checked with __INLINE_CODE_0__.
• □Installed extensions are exported/documented.
• □Each extension has a business and technical owner.
• □Unused extensions are scheduled for removal before March 31, 2027.
• □Active extensions are on current supported versions where practical.
• □Generated Cloud Functions and related resources are mapped.
• □Function generation and runtime versions are known.
• □Parameters and secrets are inventoried securely.
• □Publisher-supported replacement paths have been checked.
• □Critical extensions have a migration and rollback plan.
• □Side-effecting functions are protected against duplicate processing.
• □Non-production migration tests cover the full workflow.
• □Production cutover has monitoring and ownership.
• □Old resources are removed only after replacement stability is verified.

What should you not do?

Do not assume March 31, 2027 is the only deadline

Underlying Cloud Functions runtimes have their own lifecycle dates.

Do not leave unused extensions installed

After shutdown, normal uninstall tooling disappears and cleanup becomes manual.

Do not copy extension secrets into source code

Move secret values into proper secret-management bindings.

Do not rewrite a maintained extension before checking for an official replacement

Firebase is actively preparing migration tooling and publisher function packages.

Do not run old and new trigger handlers blindly in parallel

You can create duplicate emails, writes, jobs or external side effects.

Do not treat deployment success as migration success

Verify business behaviour, permissions, data outputs, retries and observability.

FAQs

When does Firebase Extensions shut down?

Firebase says the managed Extensions service will shut down on March 31, 2027.

Will installed Firebase Extensions stop working immediately on March 31, 2027?

No. Firebase says already-deployed underlying resources will continue running. However, managed update, reconfiguration and uninstall capabilities disappear, and older runtimes can later stop as Google Cloud decommissions them.

What is replacing Firebase Extensions?

Firebase is moving active extension workloads toward self-managed Cloud Functions, with publishers packaging extension logic for deployment into users' own 2nd gen Functions codebases. User migration tooling and detailed transition guidance are being rolled out during September 2026.

Should I uninstall all extensions now?

No. Uninstall extensions you no longer use. For active extensions, update them, inventory their dependencies and use the supported migration path when available.

Can I see all installed extensions from the Firebase CLI?

Yes. Firebase documents __INLINE_CODE_0__ for listing installed instances and __INLINE_CODE_1__ for exporting installed extension configuration into the project manifest.

Does a Flutter app need to be rewritten when an extension migrates?

Usually not if the backend contract remains the same. The main work is often replacing the extension-created backend resources with self-managed functions while preserving Firestore, Storage, Auth or event behaviour expected by the Flutter client.

Conclusion

Firebase Extensions is not disappearing in one dramatic switch where every deployed function stops on March 31, 2027. The transition is subtler and therefore easier to postpone too long.

The managed service disappears first. Existing resources may continue running, but configuration, updates, normal uninstall workflows and future runtime maintenance become your problem.

A strong migration plan is therefore:

Inventory
→ update what stays
→ remove what does not
→ map resources and runtimes
→ choose the supported replacement
→ test behaviour
→ cut over without duplicate processing
→ own the new Cloud Functions lifecycle

That work is worth starting now even if the final Firebase user-migration tooling for your specific extension has not arrived yet.

If a Firebase-backed product depends on extensions for production workflows, Softotic's custom software development service can help turn those managed extension dependencies into maintainable backend services, while mobile app development can validate that Android, iOS and Flutter clients keep the same behaviour through the migration.

Sources and references

• Firebase: Extensions Deprecation FAQ
• Firebase: Prepare Firebase Extensions for migration to Cloud Functions
• Firebase CLI reference
• Google Cloud: Supported language runtimes and base images
• Firebase Release Notes