Migration

Start with a dry run using nona migrate firebase --config ./nona.migration.json --dry-run so you can inspect how the source data will land in Nona.

Migration is a first-class Nona workflow.

The built-in CLI migrators help you move Firebase Remote Config parameters or ECS-referenced AWS Parameter Store values into:

This is important because moving off Firebase Remote Config is usually not just a data-export task. It is a product-model transition:

When to use this section

Use this migration section when:

you already have Firebase Remote Config in production
you want to preserve existing parameter work
you need a structured cutover path
you need to understand how Firebase concepts translate into Nona concepts
you want to replace ECS Parameter Store environment-variable injection with Nona server configuration

The migration docs help you reason about:

If you are already at the evaluation stage, start with:

nona migrate firebase --config ./nona.migration.json --dry-run

Then continue with Migration validation before production cutover.

The safest way to approach migration is:

That keeps migration as an operator workflow instead of an ad hoc manual rewrite.

No.

For Nona, migration is also a model transition from Firebase concepts into projects, environments, scopes, and typed entries.

Start with a dry run:

nona migrate firebase --config ./nona.migration.json --dry-run

That gives you the safest first look at how the source data will land in Nona.

Yes.

Boolean Firebase values map naturally into Nona boolean entries, which means they continue to work as feature flags after import.

Only after you validate environments, scopes, datatypes, and real application reads, not just after the import command succeeds.