Migrating PaperCut to a New Server
Migrating primary servers is considered a large administration task. Network administrators should block out at a minimum three hours, or more if you have a very large database, and should select a time where downtime will be of minimum disruption to end-users.
This article describes how to migrate the PaperCut primary server to a new system so that all data is moved to the new system. To ensure a smooth migration it is strongly recommended (actually required for versions prior to 7.2) to ensure that the versions of PaperCut on both the old and new servers is the same. The easiest way to achieve this is to upgrade the old server to the latest version, and then install the latest version on the new server.
Please read this article in full before conducting your migration.
NOTE: If you are running PaperCut on an external database (like SQL Server, PostgreSQL, Oracle) on a different machine to PaperCut follow our external database migration process.
Upgrading the old server to the latest version.
- Download the latest available version available from the PaperCut NG download page. For information on what has changed in recent releases, see the release history page. NOTE: Make sure you are eligible to upgrade to this release by checking our upgrade policy. Past releases can be downloaded here
- On the old server, install the upgrade by following the steps in the Upgrading PaperCut (upgrade procedure).
- After the upgrade is complete, check that everything is working as expected.
Migrating the data to new server.
The simplest way to migrate data to the new server is to use the backup and restore process.
- Complete all OS level setup tasks on your new server. e.g. set up your print shares, install OS updates, and perform general system testing before installing PaperCut.
- Install the latest version of PaperCut on the new server. Make sure that the new server is running the same version of PaperCut as the old server. After the installation has ran, complete the configuration wizard and import your users. Although importing the users again is not strictly required - as this data will be overridden later - it does confirm that your new server has the correct network connectivity and also saves your admin password as entered in the wizard.
TIP: If you have a very large list of users, try importing a small group of users, hence cutting down the import time.
- Backup the data from the old system. To do this follow the instructions to perform a database backup.
- Copy the backup zip file created in the backup step onto the new server.
- Stop the PaperCut Application Server by running the script
[app-path]/server/bin/<platform>/stop-server. Information about is also given here.
- Copy the
[app-dir]/server/server.propertiesfile from the old server to the new server. This file contains the built-in
adminuser password. NOTE: On Mac/Linux ensure proper permissions on the new server:
chown papercut:admin server.properties
- Copy the
[app-dir]/server/application.licensefile from the old server to the new server. This file contains your license information. NOTE: On Mac/Linux ensure proper permissions on the new server:
chown papercut:admin server.properties
- Restore the data from the old system into the PaperCut on the new server by following the database restoration instructions. On the Mac and Linux, the import commands need to be run as the
- At this point you can consider bringing across your Print Archive data. This data can be brought across completely, in-part or not at all. PaperCut is designed to be resilient to changes in Print Archive data.
- After the data had been imported and the application server restarted, check that all data has been migrated across correctly and the system works as expected. It is recommended that you perform some testing as described in our post upgrade test plan.
- Install your provided license.
- Consider turning off the old server or if running Windows, making the PaperCut services a manual start-up.
Updating user client, release station and secondary server connection details
If the server’s name and/or IP address is changing then it will be necessary to update these connection details for user clients, secondary servers, and release stations.
User clients (client software)
If user clients are being run from the share on the PaperCut server, you just need to ensure that the clients are run from the share on the new server.
If clients have been installed locally on workstations, then the connection details need to be edited/updated. The simplest option is to re-install the client using the version available from the newly installed server. The other option is to manually edit the connection details in “config.properties” file in the user client install directory. On Mac clients, the “config.properties” file is embedded in the “.app” package and installing the client again by copying it off the new server is often the easiest solution.
If you have secondary print servers, then the
ApplicationServer= setting in the “print-provider.conf” file on these servers need to be updated to point to the new machine’s network address.
To do this, open a text editor such as Notepad.
Open the file:
Locate the line starting with
ApplicationServer= and change localhost to the name or IP address of the primary server.
Restart the server so the new configuration is detected. To avoid a restart, an administrator may also choose to manually restart the PaperCut Print Provider service.
For all release stations, the “connection.properties” file located in the release station installation directory must be updated to reflect the machine’s new network address.
Web Print (Simple)
If running a simple Web Print installation on Windows, Web Print will need to be reconfigured on the new server. If the server is not a domain member, you will have to recreate the “webprint” user and reconfigure its access to Adobe Reader, the hotfolder and the PaperCut Web Print service. Review the Web Print Simple Mode setup instructions for further details.
Web Print (Sandbox)
If running a sandbox Web Print installation, check the “webprint” user’s printer and hot folder shares from the sandbox, as the relevant paths may have changed. Review the Web Print Sandbox Mode setup instructions for further details.
If running PaperCut MF, you may need to reconfigure your MFDs to connect to point to the new machine’s network address.
If the server’s hostname has changed (or if the installed printer names have changed) then you may like to rename the existing printer entries in PaperCut so that the printing history and settings are maintained. See the article How to Rename a Printer for more details.
Secondary Servers (Internet)
If you have secondary Internet servers, then the “connection.properties” file on these servers need to be updated to point to the new machine’s network address.
- Set up your printers on the new server and test before installing PaperCut.
- Consider turning your old server into a PaperCut Secondary Server reporting usage across to your new primary server. This may give you more time to map over workstations that may not be managed via a logon script, etc. You can then decommission the server at a later date.
- Consider informing your users that jobs currently in a secure hold/release queue will not be transitioned across to the new installation and they should release their jobs prior to the planned outage.
- Migrating PaperCut to a New Server - when using external database
- How to Rename a Printer
- Changing the Server Name or IP Address
- How to configure embedded software after a server migration or an IP/Hostname change
Keywords: migrate, migration, upgrade, move, moving to a new server, changing servers, transfer
Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.