> ## Documentation Index
> Fetch the complete documentation index at: https://confidence.spotify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate from Firebase to Confidence

> Learn how to migrate Remote Config parameters, conditions, rollouts, and A/B tests from Firebase to Confidence.

**Migrate from Firebase to Confidence**

Migrate Remote Config parameters, conditions, rollouts, and A/B tests from Firebase to Confidence.

This guide walks you through moving from Firebase Remote Config and Firebase A/B Testing to Confidence. You recreate your parameters as Confidence flags, your conditions as segments and rules, and your A/B tests as Confidence experiments. Then you swap the Remote Config SDK for the Confidence SDK.

> [!TIP]
>
> Use the [Confidence Flags MCP server](https://confidence.spotify.com/docs/guides/build-with-an-ai-assistant.md) with your AI assistant to create flags directly from your exported Remote Config template. Want an automated migration kit for Firebase, like the ones for [PostHog](https://confidence.spotify.com/docs/migrations/migrate-from-posthog.md) and [Eppo](https://confidence.spotify.com/docs/migrations/migrate-from-eppo.md)? [Contact the Confidence team](https://confidence.spotify.com/contact).

## Before You Begin

To migrate from Firebase, you need:

* A [Confidence](https://app.confidence.spotify.com) account with a [client](https://confidence.spotify.com/docs/capabilities/flags/clients.md) for each app that resolves flags
* Access to your Firebase project, with permission to read Remote Config and A/B Testing
* A platform that the Confidence SDK supports. The iOS SDK supports iOS 15, macOS 12, and watchOS 8 or later. If your app has targets that the SDK doesn't support, such as tvOS, keep Remote Config on those targets or resolve flags from your backend
* The [Firebase CLI](https://firebase.google.com/docs/cli), to export your Remote Config template
* Optionally, the Confidence Flags MCP server, to create flags with your AI assistant

## Key Differences

Firebase and Confidence model configuration differently. Knowing these differences up front makes the mapping easier.

* **Parameters and flags**: Remote Config serves individual key-value parameters. Confidence serves flags, where each flag has a schema of typed properties and a set of variants. A flag usually replaces a group of related parameters.
* **Conditions and segments**: Firebase evaluates conditions against a fixed set of device, app, and Google Analytics signals. Confidence evaluates segments against the [evaluation context](https://confidence.spotify.com/docs/reference/sdks/context.md), which you can extend with any attribute your app or backend knows, such as subscription plan or account age. The client SDKs also add some context for you: a `visitor_id` on JavaScript, iOS, Android, and Flutter, opt-in app, OS, device, and locale data on iOS and Android, and opt-in page data on JavaScript.
* **Randomization unit**: Firebase always randomizes on the app installation. Confidence lets you choose the randomization unit for each rule. Use the `visitor_id` for the Firebase installation behavior, or randomize on `user_id` to keep assignments consistent across devices.
* **Experiment analysis**: Firebase A/B Testing analyzes results with Google Analytics events. Confidence analyzes results with metrics computed in a data warehouse: the one [Confidence Cloud](https://confidence.spotify.com/docs/start/confidence-cloud.md) runs for you, or your own with [Warehouse Native](https://confidence.spotify.com/docs/start/warehouse-native). With Warehouse Native, if you export Google Analytics to BigQuery, you can build Confidence metrics on the same events you used in Firebase.

## Export Your Remote Config Template

Download the current template with the Firebase CLI:

```bash theme={null}
firebase remoteconfig:get -o remote-config.json
```

The template contains `parameters`, `parameterGroups`, and `conditions`. You can also download it from the Firebase console under **Remote Config > Download current config file**.

The template doesn't include your A/B tests. A parameter that you created inside an A/B test, and never added to Remote Config, might be missing from the template. List your running experiments in the Firebase console under **A/B Testing**, and search your code for every Remote Config key it reads, so that you migrate those parameters too.

## What Gets Migrated

| Firebase | Confidence |
| - | - |
| Remote Config parameter | Flag property in a [flag schema](https://confidence.spotify.com/docs/capabilities/flags/create-flags.md) |
| Parameter group | Flag with multiple properties |
| Value types (string, boolean, number, JSON) | Schema types (string, boolean, integer or double, struct). See [JSON parameters](#json-parameters) |
| Default backend value | In-app default value, or a catch-all rule. See [Rule order](#rule-order-and-default-values) |
| In-app default value | Default value passed to the SDK when resolving |
| Condition | [Segment](https://confidence.spotify.com/docs/capabilities/segments/overview) with targeting criteria |
| Conditional value | [Rule](https://confidence.spotify.com/docs/capabilities/flags/define-rules.md) that assigns a variant to a segment |
| Condition priority order | Rule order on the flag |
| User in random percentage | Allocation percentage on the segment |
| Rollout | [Rollout](https://confidence.spotify.com/docs/guides/roll-out-a-change.md) |
| A/B test | [A/B test](https://confidence.spotify.com/docs/guides/run-an-ab-test.md) |
| A/B test baseline and variants | Control and [treatments](https://confidence.spotify.com/docs/capabilities/experiments/treatments.md) |
| A/B test exposure percentage | Allocation on the experiment [audience](https://confidence.spotify.com/docs/capabilities/experiments/audience.md) |
| Activation event | Flag read at the point of exposure, which sends the [apply event](https://confidence.spotify.com/docs/reference/sdks/apply-event.md) |
| Goal metrics | [Metrics](https://confidence.spotify.com/docs/capabilities/experiments/metrics.md) from your data warehouse |

## JSON Parameters

A flag schema has string, integer, double, boolean, and struct types, but no list type. How you migrate a JSON parameter depends on its shape:

* **JSON object with fixed keys**: Model it as a struct property, or as separate properties on the flag. For example, `{"version": "1.0.0", "build_number": 1, "is_optional": true}` becomes a struct with a string, an integer, and a boolean property. Typed properties let the SDK check each value, and let you change one field in a variant without rewriting the whole object.
* **JSON that contains an array**: Model it as a string property that holds the JSON, and keep parsing it in your app as you do today. A list of sessions, products, or articles is a typical case.
* **JSON object with arbitrary keys**: Model it as a string property, since a struct needs a fixed set of keys in the schema.

Remote Config also stores numbers without distinguishing integers from decimals. Pick integer or double for each number property based on how your app reads it.

## Rule Order and Default Values

Firebase and Confidence decide the served value differently, so a direct copy of your conditions can change behavior.

In Firebase, an A/B test or rollout overrides the parameter's conditional and default values for users who take part in it. In Confidence, the [first rule that matches](https://confidence.spotify.com/docs/capabilities/flags/define-rules.md) decides the variant, and Confidence adds rules for new A/B tests and rollouts to the end of the list. If no rule matches, the SDK returns the default value from your code.

To keep the Firebase precedence, order the rules on each flag like this:

1. [Individual targeting rules](https://confidence.spotify.com/docs/capabilities/flags/define-rules.md) for test users
2. A/B test and rollout rules
3. One rule for each Firebase conditional value, in the same order as the Firebase condition priority
4. A catch-all rule, if you have one

When you launch an A/B test or rollout, Confidence adds its rule at the bottom of the list. [Reorder the rules](https://confidence.spotify.com/docs/capabilities/flags/reorder-rules.md) to move it below the individual targeting rules and above the conditional-value rules.

> [!WARNING]
>
> Any rule above an A/B test or rollout rule takes the users that match its segment. If the segment covers the whole audience, the experiment gets no users. For example, a rule that serves a value to iOS users blocks an A/B test that targets iOS users. If the segment covers part of the audience, the experiment gets fewer users than it did in Firebase.

For the Firebase default backend value, prefer an in-app default to a catch-all rule. Pass the default backend value as the default value when your code reads the flag. Users who match no rule get that value. If your in-app default differs from the default backend value today, decide which one to keep.

## Map Conditions to Segments

Some Firebase signals map to a context field that the Confidence SDKs add for you. Add the rest to the evaluation context, then target them with segment criteria.

| Firebase condition | Confidence evaluation context field |
| - | - |
| App ID, platform | On iOS and Android, `app.namespace` and `os.name`, added by the SDK's device information context when enabled. On other platforms, add a custom field such as `platform` |
| App version, build number | On iOS and Android, `app.version` and `app.build`, added by the SDK's device information context when enabled. Set `app.version` to the Version type in the context schema, and use range criteria |
| Languages | On iOS and Android, `locale` and `preferred_languages`, added by the SDK's device information context when enabled. On other platforms, add a field such as `language` |
| Country/Region | Add a field such as `country` |
| Device category | On iOS, `device.type`, such as `iPhone` or `iPad`, added by the SDK's device information context when enabled. On other platforms, add a field such as `device_category` |
| User property | Add the property as a context field |
| Custom signal | Add the signal as a context field |
| Installation ID | `visitor_id`, added automatically by the client SDKs |
| Date/Time | Schedule a rollout or A/B test to start and end at the times in the condition. The rollout or A/B test creates its own rule on the flag |
| First open | Add a field such as `first_open_time` |
| Imported segment, Analytics audience | Recreate as a [materialized segment](https://confidence.spotify.com/docs/capabilities/segments/materialized-segments.md) |

Define the fields in your [context schema](https://confidence.spotify.com/docs/capabilities/flags/context-schema.md) so they're available in the segment editor.

## Migrate Your Application Code

Replace Remote Config `fetchAndActivate` and `getValue` calls with the Confidence SDK. Confidence provides client SDKs for [iOS](https://confidence.spotify.com/docs/reference/sdks/client/ios.md), [Android](https://confidence.spotify.com/docs/reference/sdks/client/android.md), [JavaScript](https://confidence.spotify.com/docs/reference/sdks/client/javascript.md), and [Flutter](https://confidence.spotify.com/docs/reference/sdks/client/flutter.md). For server-side Remote Config, see the [server SDKs](https://confidence.spotify.com/docs/reference/sdks/overview.md).

### Migrate with an AI Assistant

With the [Confidence Docs and Flags MCP servers](https://confidence.spotify.com/docs/guides/build-with-an-ai-assistant.md) connected, give your AI assistant a prompt like this from the root of your app:

```text theme={null}
Migrate this app from Firebase Remote Config to Confidence.
1. Read remote-config.json and search the code for every Remote Config key
   it reads, including keys that aren't in remote-config.json. List the
   Confidence flags I have, then use the Confidence Flags MCP server to
   create any missing flags, grouping related parameters into one flag with
   matching property types. Model JSON objects with fixed keys as structs,
   and JSON that contains arrays as string properties. Show me the flag
   names and schemas before you create them.
2. Use the Confidence Docs MCP server to look up how to set up the Confidence
   SDK for this platform. Add the SDK dependency, check that it supports
   every target in this project, and replace the Remote Config setup with it.
   Use a placeholder for the client secret.
3. Replace every Remote Config value read, such as getValue, configValue,
   subscripts, and property wrappers, with a Confidence flag resolve.
   Keep the current in-app defaults as the default values.
4. Add every attribute that the Firebase conditions depend on to the
   evaluation context.
5. Remove Remote Config setDefaults, fetch interval, real-time listener,
   and Installations debug code once no parameters are read from Remote
   Config. Remove the Remote Config dependency, and remove the Firebase
   configuration only if the app uses no other Firebase products.
List any conditions and targets you couldn't migrate so I can review them.
Don't create catch-all rules for default values that match the in-app
defaults. Create conditional-value rules in Firebase condition priority
order, and remind me to move any A/B test or rollout rule above them.
```

Review the changes before you ship them.

### Migrate Manually

**1. Set the evaluation context**

Set the targeting key and every attribute your segments use. This replaces the signals Firebase collected automatically and any custom signals you set.

**2. Replace parameter reads**

Replace each Remote Config value read with a flag resolve for the matching property, such as `my-flag.parameter_key`. Depending on the platform, reads look like `getValue("parameter_key")`, `configValue(forKey: "parameter_key")`, `remoteConfig["parameter_key"]`, or the `@RemoteConfigProperty` property wrapper. Keep your in-app defaults as the SDK default values.

**3. Resolve flags at startup**

Replace `fetchAndActivate` with the Confidence provider initialization. On iOS and Android, choose an initialization strategy: `fetchAndActivate` waits for fresh values before startup completes, and `activateAndFetchAsync` serves cached values immediately and fetches new ones in the background for the next session. After startup, flag reads come from the local cache, so they're instant and work offline.

If your app calls `fetchAndActivate` again later, for example from a refresh button or pull-to-refresh, replace it with a fetch through the Confidence SDK, or set a new evaluation context. The minimum fetch interval settings don't apply to Confidence.

**4. Remove Remote Config setup**

Once your app reads no parameters from Remote Config, remove `setDefaults`, the minimum fetch interval settings, any `onConfigUpdated` real-time listeners, and the Remote Config dependency. If you used Firebase Installations only to register test devices, remove it too. Keep `FirebaseApp.configure()` and the Firebase configuration file if your app uses other Firebase products, such as Google Analytics.

> [!TIP]
>
> Migrate one parameter group at a time. Keep the Remote Config parameter in place until the Confidence flag serves the same values, then remove it.

## Migrate Experiments

Firebase A/B Testing results live in Google Analytics and don't transfer. For each running experiment, decide whether to finish it in Firebase or restart it in Confidence.

To restart an experiment in Confidence:

1. Create a flag with a variant for the baseline and for each Firebase variant.
2. Create an [A/B test](https://confidence.spotify.com/docs/guides/run-an-ab-test.md) with the same targeting and allocation as the Firebase exposure percentage.
3. Recreate your goal metrics in Confidence from the data you export to your warehouse. If you already use the Firebase BigQuery export for Analytics, build metrics on those tables.
4. Replace Firebase test devices. Firebase registers test devices by installation ID. In Confidence, add a rule at the top of the flag that targets your `visitor_id` or `user_id` and assigns the variant you want to test. Use the [resolver test](https://confidence.spotify.com/docs/capabilities/flags/resolve-tester.md) to check which variant a context gets.
5. If your Firebase experiment used an activation event, read the flag only where the user reaches that point. Client SDKs send the [apply event](https://confidence.spotify.com/docs/reference/sdks/apply-event.md) when your app reads the flag, not when it fetches it, so Confidence counts only exposed users.
6. Move the A/B test rule up. Confidence adds it to the end of the list, below any conditional-value or catch-all rules that match the same users. Move it below the individual targeting rules and above those rules. See [Rule order](#rule-order-and-default-values).

> [!TIP]
>
> The Confidence team can help you plan and move your running experiments. [Contact the Confidence team](https://confidence.spotify.com/contact) to get started.

Firebase A/B Testing uses one-sided tests at a fixed 5% significance level. Confidence lets you choose the test, significance level, and power for each metric, and supports sequential tests so you can check results while the experiment runs. See [Statistical Settings](https://confidence.spotify.com/docs/capabilities/experiments/statistical-settings.md).

## Other Differences

Review these differences when you map your Firebase setup:

* **Context signals**: The client SDKs add `visitor_id`, and some SDKs add opt-in app, device, and page data. Send other signals, such as country or first open time, in the evaluation context.
* **Arrays**: Flag schemas have no list type. Store JSON that contains arrays as a string property. See [JSON parameters](#json-parameters).
* **Date and time conditions**: Instead of a date and time condition, schedule a rollout or A/B test to start and end at those times. It creates and removes its own rule on the flag.
* **Remote Config personalization**: Firebase personalization, which uses machine learning, doesn't migrate. Replace it with an A/B test or rollout.
* **Real-time updates**: Confidence client SDKs optimize for instant flag reads. They resolve flags at startup and when the context changes, and serve values from a local cache, instead of pushing changes through a real-time listener.
* **Regex operators**: Confidence criteria support equality, set, range, starts-with, ends-with, and contains matching, but not regular expressions. Rewrite Firebase `matches regex` conditions as prefix, suffix, or contains matches where possible. For other patterns, compute the value in your app and send it in the evaluation context.

## Analyze Historical Experiments

Confidence can re-analyze experiments that ran on Firebase, using past assignments and metrics from your data warehouse. See the [Analyze a Past Experiment](https://confidence.spotify.com/docs/guides/analyze-an-external-experiment.md) quickstart.

> [!TIP]
>
> The Confidence team can help you export Firebase experiment data and analyze historical assignments. [Contact the Confidence team](https://confidence.spotify.com/contact) to get started.

## Related Resources

> **[Migrations Overview](https://confidence.spotify.com/docs/migrations/overview.md)**
>
> How migration kits work and how to install the plugin

> **[Set Up Confidence for Your AI Assistant](https://confidence.spotify.com/docs/guides/build-with-an-ai-assistant.md)**
>
> Set up the Confidence MCP servers for your AI assistant

> **[Analyze a Past Experiment](https://confidence.spotify.com/docs/guides/analyze-an-external-experiment.md)**
>
> Re-analyze experiments that ran on another platform

> **[SDK Integration](https://confidence.spotify.com/docs/reference/sdks/overview.md)**
>
> Integrate Confidence SDKs into your application