---
title: Separating the contact management database
related:
  - https://docs.kentico.com/13/on-line-marketing-features/configuring-and-customizing-your-on-line-marketing-features/separating-the-contact-management-database/rejoining-the-contact-management-database.md
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

> **Info:** **Enterprise license required**
>
> Features described on this page require the **Kentico Xperience Enterprise** license.

When using contact management on high‑traffic websites, the system needs to store a very large volume of data in order to keep records of all contacts, their activities and other related information. This may complicate database administration and make it difficult to perform regular backups. For these reasons, Xperience provides a way to move all tables and database objects associated with contact management to a separate database (including the currently stored data). Doing so allows easier management of the application's main database, without the need to deal with the contact data.

There can only be one separated contact management database for the entire system, even when hosting multiple websites. It is not possible to create a different database for each site.

### When should you use a separate contact management database?

- When the amount of data stored in the contact management tables is too large to back up in the same interval as the main database.

### When not to use a separate contact management database?

- If you do not store a large amount of data in the contact management database tables.
- If you do not plan on backing up your main database in frequent intervals.

### Tables affected by contact management database separation

The separation procedure affects the following database tables:

- CMS\_Consent
- CMS\_ConsentArchive
- CMS\_ConsentAgreement
- Newsletter\_ClickedLink
- Newsletter\_IssueContactGroup
- Newsletter\_Link
- Newsletter\_OpenedEmail
- OM\_Account
- OM\_AccountContact
- OM\_AccountStatus
- OM\_Activity
- OM\_ActivityRecalculationQueue
- OM\_ActivityType
- OM\_Contact
- OM\_ContactGroup
- OM\_ContactGroupMember
- OM\_ContactChangeRecalculationQueue
- OM\_ContactRole
- OM\_ContactStatus
- OM\_Membership
- OM\_Rule
- OM\_Score
- OM\_ScoreContactRule
- OM\_VisitorToContact
- Personas\_Persona
- Personas\_PersonaContactHistory

## Running the database separation

Use the following steps to separate the system's contact management data into a different database.

> **Warning:** **Warning**
>
> - It is strongly recommended to back up your database before starting the separation.
> - The database will be unavailable while the separation is being carried out, so your website will not work correctly. Run the process at a time when no visitors or editors are accessing the websites in the system. If your site is running live, we recommend taking the front-end application down manually until the database separation is complete.
> - You cannot perform database separation if you use Integrated Windows authentication on your SQL Server.

> **Note:** **Database separation on Amazon RDS**
>
> Separating the contact management database on Amazon RDS is not supported.

> **Note:** **Database separation on Microsoft Azure**
>
> If your SQL database is hosted on Microsoft Azure, you need to manually perform some parts of the procedure:
>
> - Create a new database before you launch the separation. The process cannot automatically create the separated database.
> - Move data to the separated database. The process does not move the data, it only creates the database structure.
> - Delete the separated tables from the original database.
> - [Configure your Azure project](https://docs.kentico.com/13/deploying-websites/running-xperience-on-microsoft-azure.md) to contain a connection string to the separated database.
>   - Add a new __ key to your project's _web.config_ file.

1. Open the **System** application.
2. Select the **DB separation** tab and click **Separate contact management database**.
   - This starts the database separation wizard.
3. Specify the SQL server to which you wish to transfer the contact management database and enter the connection credentials.

   - You can identify the server through its name or IP address.
   - It is possible to use a different server than the one containing the main database.
   - The separated database may be hosted on all server types [supported by Xperience](https://docs.kentico.com/13/installation/system-requirements.md).

   ![Specifying a server that will host the separated database](https://docs.kentico.com/docsassets/13/separating-the-contact-management-database/specifying_server.png "Specifying a server that will host the separated database")
4. Continue by clicking **Next**.
5. In Step 2, choose to either:

   - Create a new database for the contact management DB objects and data
   - Import the DB objects and data into an existing database on the server specified in the previous step.

     - Make sure the existing database does not contain any of the tables that are included in the separation. See the top of the topic for a list.
     - Make sure the existing database is case insensitive.
6. Type the name of the target database into the appropriate field.
7. Click **Disable tasks**.

   > **Info:** You need to prevent all [scheduled tasks](https://docs.kentico.com/13/configuring-xperience/scheduling-tasks.md) in the system from running, because the database will be unavailable during the separation process. If a task is currently being executed when you click the button, the disabling action waits until the task is finished. The tasks will automatically be enabled again when the separation is completed.

   ![Specifying a database to separate into](https://docs.kentico.com/docsassets/13/separating-the-contact-management-database/specifying_database.png "Specifying a database to separate into")
8. Click **Next** to begin the separation. The wizard displays a log while the database operations are being performed.
9. Click **Finish** in the final step of the wizard.

   - The on-line marketing data is removed from the application's main database (including the database table structure and other related objects).
   - The system re-enables the inactive scheduled tasks.

When the process is completed, all contact management data is transferred to the new database. If you view your Xperience administration project's web.config file, you can notice that an additional connection string for the new contact management database is now present in the __ section:

```html

<add name="CMSOMConnectionString" connectionString="..." />

```

You _**need to manually copy**_ the connection string for the new contact management database to your live site (MVC) project's _web.config_ file. The same applies for any other [web farm](https://docs.kentico.com/13/configuring-xperience/setting-up-web-farms.md) instances that may be running your application (either for the live site or the administration).

### Result

The new database status is reflected on the **General** tab of the **System** application, in the **Database information** section.

All functionality of the website and administration interface remains the same as before the separation.

> **Tip:** If you wish to reverse the process and return everything back to a single database, follow the instructions in [Rejoining the contact management database](https://docs.kentico.com/13/on-line-marketing-features/configuring-and-customizing-your-on-line-marketing-features/separating-the-contact-management-database/rejoining-the-contact-management-database.md).

> **Info:** **Querying data from separated databases on Azure SQL**
>
> If you are using a [Microsoft Azure SQL database](https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview) and wish to run custom queries that load data from a separated database, you need to utilize [elastic queries](https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-query-overview) (cross-database querying):
>
> 1. Set up a database scoped master key and credentials.
> 2. Define an external data source for the separated database.
> 3. Create external tables for every table that you wish to use in your queries.
> 4. Load data from the appropriate external tables in the code of your queries.
>
> For detailed information, see the [Query across cloud databases](https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-query-vertical-partitioning) article.