---
url: >-
  /statelake/administering-statelake/designer/exporting-and-importing-configurations.md
---

# Exporting And Importing Configurations

To transfer any **Module** (or configuration item) within a **Statelake** configuration into another **Statelake** configuration, it is done through the export and import process.

**Module** is simply the general term used to describe any one piece of the **Statelake** configuration, such as a **DB Connection**, a **SOAP Definition**, a **Map**, or an **Action**. The following is a list of specific configuration items that are all referred to as **Modules**, and can be exported –

* Actions
* DB Connections
* DB Definitions
* File Connections
* File Definitions
* Folders
* HTTP Connections
* Inbound Transports
* Include Files
* JSON Definitions
* Logs
* Maps
* Outbound Transports
* Parameters
* Reports
* SOAP Connections
* SOAP Definitions
* Trading Community (a single Trading Partner only)

When a **Module** is exported from the **Statelake** configuration database, it is generally referred to as being a **Template**. When a **Module** is exported, any and all other **Modules** that are dependent on that **Module** are also exported to the **Template**.

*In this example a single Map is being exported, along with all associated Modules.*

However, modules that are not dependent, will not be automatically exported. For instance, if you want to export an **Action** and all modules leading to that **Action**, then it is the **Action** that must be exported.

::: info
**Schema** files are not automatically exported, so they must be individually copied outside of **Statelake**.

**HTTP Connections** are not automatically exported as associated modules, so must be exported as individual exported items.

**Logs** are also not automatically exported. Please refer to the section on **Exporting Logs** [Exporting Logs](/statelake/administering-statelake/designer/exporting-and-importing-configurations/exporting/exporting-logs).
:::

When the **Template** is imported, it recreates the **Module** in its entirety with all its dependent **Modules**, so it is an exact copy of the original **Module** and is ready to be used immediately. For example, if you export a **DB Definition**, then the **DB Connection**s associated to it will also be exported to the **Template** and therefore these will also be imported.

**Export** is a useful tool as backup for configuration **Modules**, particularly when used with a date/time stamp as a form of version control, as it saves the item to disk and does not clog up the configuration.

The following illustration shows where **Export** and **Import** functionality sits within the options provided by **Flow** and **Statelake**. In particular, you must **Export**/**Import** within the same generation of product - from **Flow** to **Flow**, or from **Statelake** to **Statelake**. If you want to go from **Flow** to **Statelake**, you must use the **Migration Tool**.

![](/statelake/images/image-20230507-031634-9415d438.png)

There are four options to select for **Export**.

One option is to **Export** all items created within a Module, as illustrated below (Export all the **DB Definitions**).

You can **Export** an individual item as below (**Export** just the one **DB Definition** such as **Exo: Debtors Out**).

You can **Export Multiple Modules** via an option on the configuration database top menu.

Or, you can **Export** an individual **Trading Partner** from within the **Trading Community** module.

Please see the Tutorial series for more information.

## Using Copy Instead of Export

**Copy** and **Export** are similar in that they both duplicate a module item. The difference is that **Copy** duplicates the item to the same configuration only, and that copied item cannot pulled through or imported from the original into a different configuration.

If a small number of components are being updated by the change, then it may be useful to use this **Copy** feature within **Statelake Designer**, for some or all of the components being changed. For example, the **DB Definition** called **Acme – Invoices Out** could be copied and named as Acme – Invoices Out (pre change 099).

However, it is important to note that the use of copied components does not allow a direct undo of changes to components if some type of roll-back is required. Instead, it offers a means for (quickly) undoing the effect of a change by applying a second cycle of change that refers to a previous version.

If a roll-back to copied components is required, it is likely that links to underlying components (e.g. to **Definitions** from **Maps**, and to **Maps** from **Actions**) will have to be broken and rebuilt to pick up the copied versions.