---
url: >-
  /statelake/maintaining-statelake/move-statelake-to-a-different-environment/the-source-environment-space.md
---

# The Source Environment Space

To maintain data integrity and mitigate any data corruption at source, any data backup or data transfer should occur when **Statelake** is not in use. If that is not possible, then it should only occur when both the data management server and **Statelake** system is specifically made available for this purpose.

Please ensure that before any data or database manipulation is done, that you liaise with your technical advisor and/or system administrator.

There are several steps involved in the clean transfer of the **Statelake** data.

**Step 1** and **Step 2** should have been completed (if required) to prepare the target environment space. Refer to [Preparing The Target Environment Space](/statelake/maintaining-statelake/move-statelake-to-a-different-environment/preparing-the-target-environment-space).

## Step 3 - Stop StatelakeService

To ensure that no processing attempts are made while any backup or data transfer is taking place, **StatelakeService** should be stopped for any **Statelake** items that may be running.

You can easily see what services are running by accessing **Statelake Monitor**.

These correspond to the services schedule shown below.

Depending on the configurations to be copied, some or all of the **StatelakeService** entries must be stopped.

For example, the configuration of **New Config DB**  is connected to the database that is to be transferred to the target environment space. Looking at the **Current Service** of **New Config DB** in **Monitor**, you will see that there are **Actions** scheduled, and the **Service Status** is **Running**.

This service must therefore be stopped, so that no attempts are made to execute any **Action**. After the service has been stopped, **Monitor** displays the **Service Status** as **Stopped** and there are no listed **Actions**.

It is therefore safe to proceed for this item.

Please refer to [Monitor - Running Actions & Schedules](/statelake/operating-statelake/monitor-running-actions-and-schedules) for more information about **Monitor**.

## Step 4 - Stop Statelake Monitor

**Statelake Monitor** is a foreground process that essentially does what its name suggests – it communicates with the **Statelake** system and monitors and displays the status of **Statelake** services and actions.

So once **StatelakeService** has been stopped for all items, the next thing is to disable or stop **Monitor** if it is running.

Access to **Monitor** is through **Statelake Manager**. Click on **Home** in the left panel.

If **Monitor** is running, it will display a **Stop** and **Open** icon as below. To stop, simply click on the **Stop** icon.

Once it has been stopped or is not currently running, then a **Run** icon will display as below. This means that **Monitor** is stopped.

For more information about **Monitor**, please refer to [Monitor - Running Actions & Schedules](/statelake/operating-statelake/monitor-running-actions-and-schedules).

## Step 5 - Back Up Configuration Database

Each **Statelake** configuration stores all of its vital component information (**Actions**, **Logs**, **Include Files**, **Definitions**, **Maps** etc) within the configuration database that it is connected to. So by backing up the configuration database, you are backing up every component for the configuration within this convenient backup “bundle”.

And since the configuration database holds the core source data that is accessed by **Statelake**, by backing up the configuration database and then restoring it into the target environment space, this ensures that a complete copy with all components will be transferred intact.

So before anything is done, we need to have a comprehensive list of the configuration database or databases that are being transferred to the target space, and therefore a list of those that need to be backed up. This can easily be checked by using **Statelake Manager**.

Open **Manager** and select the left-hand option of **Config Databases**. You will see that under the name of every Statelake Config Database, is the name of the database that it is connected to.

In the following example, the databases are **Exercises_In_Training** and **Statelake_Actions**.

These correspond to the databases accessible in the Data Management utility such as **SSMS**, as is shown below.

So if we were only wanting to transfer the **Statelake** data for **Exercises** and **SL Actions**, we would only need to back-up the database **Exercises_In_Training** and the database **Statelake_Actions**. They would be backed up individually to a specified folder. . . one at a time.

Be aware that this backup process includes the **Log** data - and depending on the configuration being processed, this **Log** data may be extensive.

Every care must be taken during any back-up process, so to back-up these databases you will need to have the appropriate database privileges. For more information please refer to [Regular Maintenance Tasks](/statelake/maintaining-statelake/regular-maintenance-tasks).

## Step 6 - Copy Peripheral Files

There are some files that are accessed and used by **Statelake** configurations that will not be included in the backup process, and can easily be forgotten. So these files need to be manually copied from their source location to whatever target location you have selected.

These files include -

* XML schema definition files (.xsd)
* File-based Include or Script files (.inc)

Any of these that are used by the **Statelake** configurations being transferred, will all require independent manual copy and transfer to the target environment space.

Schema files should be found and copied from the \Schema\ sub-directory under the data directory.

Include files should be found and copied from the \Script\ sub-directory under the data directory.

### Ready to proceed to the next Step.