Migrate from Firebase to Confidence - Confidence Documentation

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.

Use the Confidence Flags MCP server 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 and Eppo? Contact the Confidence team.

Before You Begin

To migrate from Firebase, you need:

A Confidence account with a client 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, 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, 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 runs for you, or your own with 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:

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
Parameter group	Flag with multiple properties
Value types (string, boolean, number, JSON)	Schema types (string, boolean, integer or double, struct). See JSON parameters
Default backend value	In-app default value, or a catch-all rule. See Rule order
In-app default value	Default value passed to the SDK when resolving
Condition	Segment with targeting criteria
Conditional value	Rule 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
A/B test	A/B test
A/B test baseline and variants	Control and treatments
A/B test exposure percentage	Allocation on the experiment audience
Activation event	Flag read at the point of exposure, which sends the apply event
Goal metrics	Metrics 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 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:

Individual targeting rules for test users
A/B test and rollout rules
One rule for each Firebase conditional value, in the same order as the Firebase condition priority
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 to move it below the individual targeting rules and above the conditional-value rules.

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

Define the fields in your context schema 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, Android, JavaScript, and Flutter. For server-side Remote Config, see the server SDKs.

Migrate with an AI Assistant

With the Confidence Docs and Flags MCP servers connected, give your AI assistant a prompt like this from the root of your app:

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

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.

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.

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.

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.

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:

Create a flag with a variant for the baseline and for each Firebase variant.
Create an A/B test with the same targeting and allocation as the Firebase exposure percentage.
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.
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 to check which variant a context gets.
If your Firebase experiment used an activation event, read the flag only where the user reaches that point. Client SDKs send the apply event when your app reads the flag, not when it fetches it, so Confidence counts only exposed users.
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.

The Confidence team can help you plan and move your running experiments. Contact the Confidence team 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.

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.
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 quickstart.

The Confidence team can help you export Firebase experiment data and analyze historical assignments. Contact the Confidence team to get started.

Migrations Overview

How migration kits work and how to install the plugin

Set Up Confidence for Your AI Assistant

Set up the Confidence MCP servers for your AI assistant

Analyze a Past Experiment

Re-analyze experiments that ran on another platform

SDK Integration

Integrate Confidence SDKs into your application

​Before You Begin

​Key Differences

​Export Your Remote Config Template

​What Gets Migrated

​JSON Parameters

​Rule Order and Default Values

​Map Conditions to Segments

​Migrate Your Application Code

​Migrate with an AI Assistant

​Migrate Manually

​Migrate Experiments

​Other Differences

​Analyze Historical Experiments

​Related Resources

Migrations Overview

Set Up Confidence for Your AI Assistant

Analyze a Past Experiment

SDK Integration

Before You Begin

Key Differences

Export Your Remote Config Template

What Gets Migrated

JSON Parameters

Rule Order and Default Values

Map Conditions to Segments

Migrate Your Application Code

Migrate with an AI Assistant

Migrate Manually

Migrate Experiments

Other Differences

Analyze Historical Experiments

Related Resources