Environment export and import lets you copy feature configurations from one environment to another and even copy features from one Unleash instance to another.
When exporting, you select a set of features and **one** environment to export the configuration from. The environment must be the same for all features.
Then, when you import, you must select **one** environment and **one** project to import into. All features are imported into that project in that environment. If Unleash is unable to import the configuration safely, it will tell you why the import failed and what you need to fix it (read more about [import requirements](#import-requirements).
* [activation strategies](/reference/activation-strategies.md) including [constraints](/reference/strategy-constraints.md) and references to [segments](/reference/segments.mdx)
Importantly, while references to [segments](/reference/segments.mdx) are exported, the segments themselves are **not** exported. Consult the [import requirements](#import-requirements) section for more information.
You can export features either from a project search or the global feature search. Use the search functionality to narrow the results to the list of features you want to export and use the export button to select environment. All features included in your search results will be included in the export.
<Figure caption='Feature flag lists can be filtered using the search bar. Once filtered, you can use the "export current selection" button to export the configuration for those features.' img="/img/export.png"/>
* **validation** - you will get feedback on any errors or warnings before you do the actual import. This ensures your feature flags configurations are correct. You will not be able to finish the import if you have errors. Warnings don't stop you from importing.
* **import** - the actual import that creates a new configuration in the target environment or creates a [change request]/reference/change-requests.md) when the environment has change requests enabled
### Import requirements
Unleash will reject an import if it discovers conflicts between the data to be imported and what already exists on the Unleash instance. The import tool will tell you about why an import is rejected in these cases.
The following sections describe requirements that must be met for Unleash not to stop the import job.
#### Context fields
When you import a custom context field **with legal values defined**:
If a custom context field with the same name already exists in the target instance, then the pre-existing context field must have **at least** those legal values defined. In other words, the imported context field legal values must be a subset of the already existing context field's legal values.
When you import custom context fields without legal values or custom context fields that don't already exist in the target instance, then there are no requirements.
Custom context fields that don't already exist in the target instance will be created upon import.
#### Segments
If your import has segments, then a segment with the same name must already exist in the Unleash instance you are trying to import into. Only the name must be the same: the constraints in the segment can be different.
If your import has a parent feature dependency, then the parent feature must already exist in the target Unleash instance or be part of the import data. The existing feature is identified by name.
If your import contains custom strategies, then custom strategies with the same names must already exist in the target Unleash instance. The custom strategy definitions (including strategy parameters) that exist in the target instance do not otherwise need to match the custom strategy definitions in the instance the import came from.
#### Existing features
If any of the features you import already exist in the target Unleash instance, then they must exist within the project you're importing into. If any features you are attempting to import exist in a **different** project on the target instance, the import will be rejected.
The import validation system will warn you about potential problems it finds in the import data. These warnings do not prevent you from importing the data, but you should read them carefully to ensure that Unleash does as you intend.
The following sections list things that the import tool will warn you about.
#### Archived features
The import tool will not import any features that have already been archived on the target Unleash instance. Because features are identified by their name, that means that if a feature called `feature-a` has been created and archived on the target Unleash instance, then a feature with the same name (`feature-a`) will not be imported.
If you permanently delete the archived `feature-a` from the target instance, then the new `feature-a` (in the import data) **will** be imported.
Unleash will verify that any custom strategies you are trying to import have already been defined on the target instance. However, it only does this verification by name. It does **not** validate that the definitions are otherwise the same or that they have the same [configuration parameters](/reference/custom-activation-strategies.md#parameters).
If change requests are enabled for the target project and environment, the import will not be fully applied. Any new features will be created, but all feature configuration will be added to a new change request.
If change requests are enabled, any permissions for **Create activation strategies**, **Delete activation strategies** and **Update variants** are not required.
The instance import/export API was designed to export all feature flags (optionally with strategies and projects) from one Unleash instance to another. When it was developed, Unleash had much fewer features than it does now. As such, the API lacks support for some of the more recent features in Unleash.
On the other hand, the environment import/export feature was designed to export a selection of features based on search criteria. It can only export data from a single environment and only import it to a single environment. It also only supports importing into a single project (although it can export features from multiple projects).
Further, the environment import/export comes with a much more stringent validation and will attempt to stop any corrupted data imports.
You can also import on startup by using an import file in JSON format and the import will be applied on top of existing data. Currently the startup import supports the same data supported in OSS import.
Unleash lets you do this both via configuration parameters and environment variables. The relevant parameters/variables are:
