This article describes how to move an existing SystemWeaver server-side installation from one server machine to another. 


Taking a Backup

Since all of the installation, configuration, and data files already exist in the current server installation, you will not need to create any new files. We highly recommend that you take a backup of all files, just as we recommend for upgrades. The files to back up are:


If you are running a MS SQL or Oracle database, you will follow the database backup routines for your database type. However, if using the SystemWeaver file repository, you will want to back up the file repository as the file repository is not located in the MS SQL or Oracle database.

Moving the Installation

Simply zip each of the following, and securely move them to the new machine: 

  • The complete Server directory
  • The complete ServerMonitorService directory (earlier versions include these files in the Server directory)
  • The SQLite database file (if in use)
  • The complete file repository directory, if in use. If running a file-based repository, this should include the index file along with the data folder. Do not modify any content.
  • The complete Notification Server directory (if in use)
  • The client and API files. This is recommended.
  • The most recent log file(s). This is optional.


Once you have all of the files in their desired location, you can unzip each of them. 


Below is an example structure for both the server and client applications, and the data files.  


Tip: Unless you wish to have a different folder structure from the one on the previous server machine, we recommend replicating the same folder structure on the new machine. This way, the paths in the various configuration files may only need minimal changes. 

Reviewing All Configuration Files

The configuration files and prop files (for logging) for the server application and any other SystemWeaver server application in use still reflect the paths on the previous machine. If you use the same exact structure on the new machine as on the old, then it should work without any modifications to the configuration files. If the paths are different than before, and/or if you want to change the location where log files generate, you will need to update these files accordingly.

Testing the Server Installation

Always test the newly installed SystemWeaver server using the swTestServer application first, before you run it as a Windows Service. See Testing a SystemWeaver Installation.

If using a Notification Server, test that as well using the swTestNotificationServer application. See Testing the Notification Server Configuration.

Installing the Server Monitor Service

Once you have successfully tested all of the server-side applications in use directly as executables, you are ready to install the Server Monitor Service, and run the server-side applications as a service.

Verifying All Security Applications

Be sure to adjust any firewalls or other security applications to allow traffic between the new server machine and the database machine (if running MS SQL or Oracle) and the client users.


You will find troubleshooting articles on the support portal. However, feel free to contact us via support@systemweaver.com for assistance.


Tip: Instructions for how to set up a new SystemWeaver server can be found in the SystemWeaver Server Installation Manual or in Installing a New SystemWeaver Server article series. These articles may be of help as a reference when moving an existing server installation. 

Replacement License Keys

Once the installation is in place, it will need new license keys. Contact support@systemweaver.com to request new keys for the server move. 

Stopping the Old Installation

Typically, you will want to stop the old server-side applications once you have the new installation running. This is to block users from logging in to the old server and working. If users should no longer be able to access the old installation at all, stop the server application entirely. Users will receive a message the the server is not available when they attempt to log in. It is important to notify users of the new Server (and Port) information prior to the move to lessen confusion.

Leaving Old Server Running For Transition Period

Alternatively, you can keep the old server running for a short transition period.

Deactivating Accounts

If a few users should be able to continue to access the old installation for a short transition period, just to confirm and verify a successful move, we recommend deactivating all other user accounts. The quickest way to do this is to use the Deactivate all option. Then reactivate the few users completing any desired checks. This is the option we recommend if youhave the older server running for a short period.


Assigning Read-only Access to Items and Issue Projects

You can also keep it running in read-only mode for a short period of time. 


Viewer Role for Item Access

If you prefer to leave access in place for all or a few users for a short transition period, there is the option of simply assigning the Viewer role to all users, and leaving the accounts activated until the server is decommissioned. However, this may cause confusion when they are logged in as to why the system is now read-only, or why data is not updated, etc.


Read-only Access to Projects and Issues

Access to projects is handled separately from items. There are a couple of options here as well. You can provide read-only rights to projects or remove access entirely to a project, or all projects.


When the license(s) is removed, users will immediately have read-only rights to their open projects. Open projects are those projects that are currently open on a tab in the Projects module. Users can continue to view the issues in those projects, but cannot open any additional projects (using the Open projects button) if those projects were closed when the license(s) was removed. 


If you have chosen to assign the Viewer role to users, then for Projects, you will need to manually remove Write and/or Change rights so that users only have Read access to their projects. This option allows users to view projects that are currently open in the GUI, and also allows them to open projects that are not currently in view (using the Open projects button). You simply remove Write and/or Change rights by right-clicking on the user entry on the Project > Users tab and deselecting the Write and/or Change option. This must be done for each user and/or group, one at a time, and for each project. The Administrator completing this work must have access to all projects that need to be updated. If they do not, they will not be able to view all of the projects in their session and may miss removing Write/Change rights from users. Note that this can be very time-consuming if there are many members in the projects, and many projects.


Remove all Access to Projects

To remove all access to the projects so that users cannot view the project(s) at all, see How to "Close" a Project. It entails removing users from the project entirely. This should be done for each project. Note that this can be very time-consuming if there are many members in the projects, and many projects. 

Things to Consider

Since users are only human, even the best efforts will not always be enough to avoid users accessing the old installation if you keep it running for a short transition period and allow them to maintain their full write access. 

  • If you opt to manually remove rights to projects, this should be done outside of business hours just prior to roll-out of the new installation to users. If that is not possible, consider stopping the old server temporarily after roll-out while removing access to projects. This is all to ensure that users do not continue modifying issues in the old server should they log in there by mistake to work. 
  • If a Microsoft ClickOnce distribution package is being used for the new installation, be sure to instruct users to uninstall their old ClickOnce installation prior to installing the new package.