Migrating from Firebase Remote Config

This guide is for apps that read their remote configuration from Firebase Remote Config and want to move it to ConfigDirector. It maps the Remote Config concepts onto ConfigDirector's, walks through recreating the parameters as configs, and shows how to switch each SDK over so that both services run side by side until you remove Remote Config.

If you are new to ConfigDirector, read Core Concepts first. It takes a few minutes and makes the mapping below easier to follow.

Before you start

1. Export the Remote Config template. The Firebase console, the Firebase CLI (firebase remoteconfig:get -o remoteconfig.template.json), and the REST API all export the template as JSON, with every parameter, its default and conditional values, its value type, and the project's conditions. That file is the list you work from. See Firebase's template documentation.
2. Decide which parameters not to move. A migration is the best moment to clean up. A parameter that has had the same value everywhere since it was added, or that no shipped version of the app still reads, has nothing left to decide. Hardcode that value instead of recreating the parameter.
3. Create your ConfigDirector organization and project. Sign up and create one project for the app. If you kept one Firebase project per stage, such as my-app-dev and my-app-prod, they become environments of this one project: Test and Production are created for you, and you can add more. Mark the environments that serve real traffic as live.

How the concepts map

Parameters and values

Conditions

Remote Config evaluates values per app instance, from signals it collects itself. ConfigDirector evaluates values per context: the user, device, or other entity your app says it is evaluating for, with the traits your app gives it. Most Remote Config conditions become a condition on a trait that your app sets.

Remote Config combines the clauses of a condition with AND, and so does a ConfigDirector rule: every condition of a rule must match. Where Remote Config applies the first matching conditional value in the order the conditions are listed, ConfigDirector applies the first matching rule.

Experiments and rollouts

Fetching values

Recreate the parameters

Create the configs in ConfigDirector while Remote Config keeps serving your app. Nothing changes for your users until the SDKs switch over.

For each parameter in the exported template:

1. Create a config with the same key, the role and type from the tables above, and a lifetime: Temporary for a parameter you plan to remove once a feature is fully released, Permanent for one that stays. Set its initial value to the parameter's default value.
2. In each environment, recreate the conditional values as conditional rules, in the same order, with the parameter's default value as the default targeting rule value. A Firebase project per stage maps onto one environment each; a single Firebase project maps onto Production, and Test gets the values you want while developing.
3. Check a few contexts with the targeting rules tester. The result should be the value Remote Config serves them.

There are three ways to do this:

• The dashboard, for an app with a few parameters. The config form and the targeting rules editor cover everything above.
• The Terraform provider, if you want the configuration as code from the start. The ConfigDirector Terraform provider has configdirector_config for the config and configdirector_config_targeting_rules for the rules of each environment.
• The MCP server, for a template with many parameters. Connect the MCP server to your coding assistant, give it the exported template, and ask it to create the configs and their targeting rules. Review what it created in the dashboard before switching any SDK.

Switch the SDKs

Switch one platform at a time. Pass the parameter's in-app default as the in-code default value, so that a config that is missing, or read before the client is ready, still gives the result users get now.

Initialize the client

Create one client when the app starts, with the client SDK key of the environment the build runs against, and initialize it. Where Remote Config needs setDefaults, fetchAndActivate, and a minimum fetch interval, ConfigDirector needs the client and one call:

import 'package:configdirector_flutter_client_sdk/configdirector_flutter_client_sdk.dart';

final client = ConfigDirectorClient(clientSdkKey: 'YOUR-CLIENT-SDK-KEY');

await client.initialize();

import com.configdirector.ConfigDirectorClient

val client = ConfigDirectorClient(applicationContext, "YOUR-CLIENT-SDK-KEY")

// A suspend function: call it from a coroutine.
client.initialize()

import ConfigDirector

let client = try ConfigDirectorClient(clientSDKKey: "YOUR-CLIENT-SDK-KEY")

await client.initialize()

import { createClient } from "@configdirector/client-sdk";

export const client = createClient("YOUR-CLIENT-SDK-KEY");

await client.initialize();

initialize returns when the first values arrive or after its timeout. If your users are often on poor connections, do not await it: reads return the in-code default value until values arrive, and then the real values, exactly as Remote Config does before the first activate.

Read a value

Each read takes the key and the in-code default value, and the default decides the type the value is read as:

// Before: remoteConfig.getBool('new_checkout')
final newCheckout = client.getValue('new_checkout', false);

// Before: remoteConfig.getInt('max_items')
final maxItems = client.getValue('max_items', 20);

// Before: remoteConfig.getBoolean("new_checkout")
val newCheckout = client.value("new_checkout", false)

// Before: remoteConfig.getLong("max_items")
val maxItems = client.value("max_items", 20)

// Before: remoteConfig["new_checkout"].boolValue
let newCheckout = client.value(for: "new_checkout", default: false)

// Before: remoteConfig["max_items"].numberValue
let maxItems = client.value(for: "max_items", default: 20)

// Before: getBoolean(remoteConfig, "new_checkout")
const newCheckout = client.getValue("new_checkout", false);

// Before: getNumber(remoteConfig, "max_items")
const maxItems = client.getValue("max_items", 20);

A JSON parameter that you parsed from getString is read as JSON directly: pass an object or a map as the default and the SDK returns the parsed value.

Follow changes

Remote Config's real-time listener tells you a new template exists, and you call activate and re-read. ConfigDirector's watch, and the streams and flows of the mobile SDKs, give you the value itself, first the current one and then every change:

// Before: remoteConfig.onConfigUpdated.listen((event) async { await remoteConfig.activate(); ... })
final subscription = client.watch('new_checkout', false).listen((newCheckout) {
  // Rebuild with the new value
});

// Before: remoteConfig.addOnConfigUpdateListener(...) then remoteConfig.activate()
lifecycleScope.launch {
    client.values("new_checkout", false).collect { newCheckout ->
        // Update the UI with the new value
    }
}

// Before: remoteConfig.addOnConfigUpdateListener { ... remoteConfig.activate() }
for await newCheckout in client.values(for: "new_checkout", default: false) {
    // Update the UI with the new value
}

// Before: onConfigUpdate(remoteConfig, ...) then activate(remoteConfig)
client.watch("new_checkout", false, (newCheckout) => {
  // Render with the new value
});

In Flutter, pair watch with a StreamBuilder; in Jetpack Compose, use configValue from the Compose artifact; in SwiftUI, read the stream in a task. Each SDK page shows the pattern for its framework.

Give the context what your rules need

Remote Config knew the country, language, and app version of each installation on its own. ConfigDirector knows the app name and version through the SDK's metadata, and everything else from the context your app provides. Set the traits your targeting rules use, and update the context when the user signs in or out:

await client.initialize(
  const ConfigDirectorContext(
    id: '12345',
    traits: {'country': 'US', 'language': 'en', 'platform': 'ios'},
  ),
);

// On sign out: an anonymous context
await client.updateContext(const ConfigDirectorContext());

client.initialize(
    ConfigDirectorContext.build {
        id("12345")
        trait("country", "US")
        trait("language", "en")
        trait("platform", "android")
    },
)

// On sign out: an anonymous context
client.updateContext(ConfigDirectorContext.build { anonymous(true) })

await client.initialize(
    context: ConfigDirectorContext(
        id: "12345",
        traits: ["country": "US", "language": "en", "platform": "ios"]
    )
)

// On sign out: an anonymous context
await client.updateContext(ConfigDirectorContext(isAnonymous: true))

await client.initialize({
  id: "12345",
  traits: { country: "US", language: "en", platform: "web" },
});

// On sign out: an anonymous context
await client.updateContext({ anonymous: true });

A context given without an identifier is anonymous: the values are still evaluated for it, with a stable identifier derived from the SDK instance, and it is never stored or shown in the dashboard.

The SDK for each platform

Every platform also has an OpenFeature provider, if you prefer to code against the vendor-neutral OpenFeature API.

Verify, then remove Remote Config

Once a build reads a config from ConfigDirector:

• Evaluation Activity on the config shows the values being served in each environment. See Evaluation Activity.
• Alerts catch the mistakes a migration makes: a key the app asks for that does not exist, a config read with the wrong type, an in-code default value that drifts from the value served, and the default value served more often than expected. See Alerts.
• For a value you rolled out by percentile, the assignment starts afresh: a user who was in Remote Config's 10% is not necessarily in ConfigDirector's. Switch over at a point in the rollout where that is acceptable, or at 0% or 100%.

Keep Remote Config in the app until the versions that read it have faded from your user base, then remove the dependency and delete the parameters from the template. From then on, the config lifecycle tells you when each temporary config has settled and can be removed from the code too.