Move a Bizagi application from one production server to another

2 Years Ago


The following article illustrates all the steps involved when moving your Bizagi production environment to a new location. Note that moving the Bizagi production environment to a new location implies that:

1. Your current Bizagi BPM server will no longer be used, and you want to use a different physical server instead.

2. You also need to move the database into a different physical database server.

3. Your current Bizagi BPM server has an active license which you need to relocate to the new location. 

Within the steps illustrated below, connectivity between your current Bizagi BPM server and the servers at the new location is required. This procedure does not consider a clustered BPM server setup.

Applies to

Bizagi .NET 10.x or later.


1. Move your licenses and the BPM server.
Follow the detailed guideline about moving the active license and the BPM server components (i.e, the Web application, the Scheduler service), as described at the official documentation at (the chapter mentioning "move a server").

Recall that the above procedure requires a connection between your current Bizagi BPM server and the server to be designated as the new BPM server.

Checkpoint: upon completing this procedure, you should be able to verify that your new BPM server is operational. However, note that this new BPM server is accessing to the database at the current database server. 

2. Move uploaded documents (if applicable)

Consider if you need to relocate the uploaded documents as well (optional). This applies mainly when storing such documents in a file server, and when you will relocate a new server for this purpose as well.

This step is not applicable when using an ECM system, for instance, as your documents repository.

To move uploaded documents, make sure you copy the physical folders containing these documents into the new location. When doing so, make sure you reconfigure this new location in Bizagi, through the upload path parameter and by using the Management Console, as described at

Checkpoint: upon completing this procedure, you should be able to verify that old cases can access already uploaded documents.  If you did modify the upload path parameter, running an IISReset may be required.

3. Move the database

To change the location of your database server, create a backup of your Bizagi database and restore it at the new database server.

If you are using SQL Server, creating a full backup and restoring is done through SQL Server Management Studio, as described at and

If you are using Oracle, creating a database backup and restoring it is done through the export datapump and import datapump utilities, as described at and

Checkpoint: upon completing this procedure, you will have two identical instances of your Bizagi database. Only after ensuring this (that the database was successfully restored at the new database server), proceed to delete the instance at the old database server. You may choose to set it offline, rename it, or detach it instead if you are not completely certain of deleting it.

4. Reconfigure the new BPM server to access the new database server

To easily reconfigure the database connection used by your new BPM server, use Bizagi Management Console to open the newly registered project at the new BPM server (this new project was produced when using the "move server" option).

To do so, use the open existing project option. Bizagi Management Console will show a prompt for you to reconfigure the database connection. Use the appropriate credentials and reference to the new database server.

Checkpoint: at this point, you may see that both the new BPM and new database servers are operational. However, you still need to ensure that your project environments location is updated within the Bizagi configuration, in order to avoid potential issues in future deployments.

5. Reconfigure the environments mapping for Bizagi deployments

To ensure that future deployments will have accurate references of your production environment, (in other words, targeting the new servers instead of the old ones), ensure the following:

If you are relying on the Advanced Deployment tool ( for process deployments, update the value of the DSNDB key as configured inside of these files: Export.exe.configCreateImport.exe.config and ApplyImport.exe.config. The value of the DSNDB key should specify the connectivity to the new database server.

If you are using the One-click Deployment feature instead (, then you may modify the deployment map at the development environment and review this setting when configuring a new deployment to the production environment through the One-click Deployment.

Checkpoint: at this point you may carry out further configuration tasks of your system architecture such as: reconfiguring the BPM server's IIS SMTP service if being used, applying/verifying any customizations done in your project (e.g, any special web.config keys being used such as the ones for case links in e-mails, any style overrides, any proxy server configuration that points to your BPM server, or possibly additional .dll components placed at the bin folder).

Only after ensuring that your new location is fully considered by your infrastructure, you may proceed to delete the components at the old BPM server.


Last Modified:2 Years Ago
Last Modified By: AndresM
Level: Advanced
Rated 1 star based on 1 vote
Article has been viewed 7.9K times.