“I’m a Systems Administrator about to set up a new print server on a newer/different operating system and I want to know how to migrate the PaperCut Application Server. What are the best steps to take?”

Our best server migration advice

• Read this article end-to-end before you start.
• Do the Preparation Checklist tasks first.
• Schedule downtime and perform the Cutover Checklist tasks when you are ready to transition to the new server.
• Have a backup plan and be ready to revert to the old server in an emergency.
• To keep things simple give the new PaperCut server the same IP address and Hostname as the old one (but don’t let them be online at the same time to avoid an IP address conflict). This is so that other PaperCut components on the network won’t need to be reconfigured (like the User Client, MFPs running the PaperCut embedded application, Direct Print Monitor, Secondary Servers, Site Servers, Payment Gateways, Web Print Sandboxes, etc…). Changing the IP address of your PaperCut server is a wholly different task which we recommend tackling separately, where you will need to follow the instructions in these additional articles: Changing Server Name or IP and How to configure embedded software after a server migration or an IP/Hostname change.
• For PaperCut MF customers, we recommend you contact your PaperCut Partner for consultation and technical assistance (their details can be found on the About page of your PaperCut server).
• There are different steps in this article depending on whether your PaperCut server is configured to use an internal database or an external database (like SQL). If you have an external database, be sure to “comment out” the database connection details in Step 4, so that you won’t wind up with two servers connecting to the same database! Alternatively if you’re only looking to migrate your external database (e.g. from database server 1 to database server 2), have a look at Migrating your database server.
• Migrating to a cloud-hosted server? Check out our Best Practices for Private Cloud Hosting for some extra homework before continuing!

Preparation Checklist

• 1. Set up and test the print queues on the new server
• 2. Install the same version of PaperCut on both servers
• 3. Copy the License file to the new server
• 4. Review and copy the server.properties file to the new server
• 5. Migrate other PaperCut components as needed
  • 5a. Custom Certificate and KeyStore
  • 5b. Payment Gateways
  • 5c. Mobility Print
  • 5d. Print Archiving
  • 5e. Web Print
  • 5f. Print Deploy

Cutover Checklist

• 6. Inform users of the scheduled downtime for the migration
• 7. Migrate the database to the new PaperCut server
• 8. Power off the old server, or disable the network interface.
• 9. Post Migration considerations

1. Set up and test the print queues on the new server

If PaperCut and your print server are one in the same, then make sure you setup all of the print queues on the new server and test printing before installing PaperCut. These steps will vary depending on whether you have a Windows, macOS, or Linux print server.

On Windows, this means opening Print Management Console on the new server then adding your printers using the Add Printer Wizard one by one or you can use the Print Server Migration feature built into Windows to quickly migrate all your queues, drivers, ports, and settings.

We recommend that the print queues on the new server are named identically, otherwise clients on the network that print through this server may have trouble connecting to the hosted print queues. If the printer names or server hostname will change as part of the migration you may want to rename the existing printer entries in PaperCut so that the printing history and settings are maintained and you don’t end up with two separate entries for each printer. See the article How to Rename a Printer for more details.

If you have queues using the LPR protocol or have the PaperCut LPD Service installed previously on your original Print Server, you will need to re-install the PaperCut LPD Service on the new Print Server that you are migrating to. This will ensure LPR jobs submitted from macOS and Linux clients can be understood and accepted by the Windows Print Server, allowing the hosted queues to pass on the jobs to the printing devices. Check out this article for more information. Some organizations can skip these steps if no printing is done through the PaperCut server. This is more common in larger organizations that have a dedicated PaperCut server and track printing only through PaperCut Secondary Servers, Site Servers, or the Direct Print Monitor.

2. Install the same version of PaperCut on both servers

When migrating PaperCut, we recommend having the same version of PaperCut is running on both the old and new server.

Note: If you had migrated from e.g. NG to MF on your old server, and your old server has PaperCut installed in the Program Files/PaperCut NG directory, but your new server has PaperCut installed in the Program Files/PaperCut MF directory, that’s ok! All the steps in this document will still apply.

The easiest way to ensure this is to upgrade to the latest version of PaperCut by logging into your server as Admin, navigate to the About page, then click “Check for updates” to get the latest version. Then run this installer on both the old and new servers.

To upgrade, your PaperCut Maintenance and Support agreement must be up to date. Having a current Support agreement will also ensure timely support if anything goes awry. Please check our upgrade policy if you have questions.

If upgrading before the migration is not an option (which may be the case if your PaperCut server is still running on a 32-bit OS) then you can still obtain older versions of PaperCut. PaperCut NG customers can still download past versions from our website while PaperCut MF customers will need to reach out to their PaperCut Partner for past versions.

Steps:

1. Log into your existing PaperCut server as Admin.
2. Navigate to the About page
3. Click Check for updates button.
4. Download the latest installer and run it on both the old and new servers.
5. Follow the prompts to finish the installation wizard and synchronize users with your directory.

Test and confirm: After installing PaperCut on the new server, navigate back to the About page to check your server version and confirm it is the same version as the old PaperCut server.

Also make sure that PaperCut on the new server can communicate with your user directory by navigating to the Options page, then open the User/Group Sync tab, and scroll down to the Test Settings button.

3. Copy the License file to the new server

You will need to get your new server licensed to run PaperCut by copying the license file from the old server, then install it on the new one.

Steps:

1. Log into the old server running PaperCut.
2. Navigate to the server folder in where PaperCut is installed, [application-directory]/server/. (On a 64-bit Windows server running PaperCut MF this would be C:\Program Files\PaperCut MF\server\.)
3. Copy the file named application.license to the new server.
4. Log into the web interface of the new server as administrator.
5. Browse to the About section. Next to Register choose to install the license file that was copied previously.
6. Click Install License.

Test and confirm: Verify license information is correctly listed in the About page.

4. Review and copy the server.properties file to the new server

This file contains many important configurations and customizations which may have made on your previous PaperCut server. This includes:

• Hashed admin credentials
• Custom SSL/TLS Certificate details (if one has been installed)
• Listening ports (like 80 and 443)
• Security settings like the allowed Ciphers and Protocols list
• Database configuration details (if an external database is used)

These exact steps will vary depending on whether PaperCut is configured to use the default built-in Derby database, or an external database (like SQL Server, PostgreSQL, Oracle). Look on the About page next to System Info to see what type of database you have.

Steps:

1. Log into the old server running PaperCut.
2. Navigate to the server folder in where PaperCut is installed, [application-directory]/server/. (On a 64-bit Windows server running PaperCut MF this would be C:\Program Files\PaperCut MF\server\.)
3. Copy the server.properties file to the new server.
4. Only if PaperCut is configured to connect to an External Database, then edit the new copy of the server.properties file so that the database connection details are “commented out”, by putting a # symbol at the beginning of each line like the example below. This will prevent your new PaperCut server from prematurely connecting to the Database. Later, when it is time to cut-over to the new server we will un-comment these lines.

   • #database.type=SQLServer
     #database.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
     #database.url=jdbc:sqlserver://dbsrv01:1433;databaseName=Papercut
     #database.username=PaperCut_DB
     #database.password=1234
     

5. Restart the new PaperCut server or Stop and Start the PaperCut Application server serivce for the change to take effect.

Test and confirm: The simplest way to check if this was successful is that your new PaperCut server should now use the same admin password as the old PaperCut server.

Also be aware that if your organization has installed a custom SSL certificate specified in the server.properties file, you may need to follow the steps in the next section to move the KeyStore file before the new server can successfully start.

5. Migrate other PaperCut components as needed

Some of these next steps will be optional depending on what PaperCut features your organization uses.

5a. Custom SSL Certificate and KeyStore

If your organization installed a custom SSL certificate on the PaperCut server, then you will want to copy the Keystore file from your old PaperCut server to the new one.

If your organization still uses the default self-signed certificate, you can safely skip this section.

Steps:

1. On the old PaperCut server, navigate to where the Keystore is saved in the PaperCut application directory, usually this is [application-directory]/server/custom. (On a 64-bit Windows server running PaperCut MF this would be C:\Program Files\PaperCut MF\server\custom.) The exact KeyStore path and file name is defined in the server.properties file on the line #server.ssl.keystore=custom/my-ssl-keystore.
2. Copy this KeyStore file to the same folder on the new server.
3. Restart the new PaperCut server or Stop and Start the PaperCut Application server serivce for the change to take effect.

Test and confirm: Verify the new certificate works by opening a web browser on the new server and navigating to https://localhost:9192, then check the certificate details in your browser.

5b. Payment Gateways

If your organization configured PaperCut to use a Payment Gateway like PayPal or Authorize.net please make sure to reinstall the Payment Gateway module, and copy the configuration files.

If your organization does not use Payment Gateways, you can safely skip this section.

Steps:

1. Download the Payment Gateway Module.
2. Install it on the new PaperCut server.
3. Copy any files located in [application-directory]/server/lib-ext/ from the old server to the new one. (On a 64-bit Windows server running PaperCut MF this would be C:\Program Files\PaperCut MF\server\lib-ext.)
4. Restart the new PaperCut server or Stop and Start the PaperCut Application server serivce for the change to take effect.

Test and confirm: Your organization probably has port forwarding rules or IP address whitelisting in place to ensure traffic from the Payment Gateway provider goes to your old PaperCut server. You’ll have to amend these rules to work with the new server. So, the best time to test and confirm payment gateway transactions succeed is after completing the Cutover described below. In other words, complete the server migration or name change, verify your network security implementation has the new PaperCut server addresses, then try adding credit to a user account. Consider doing a test cutover outside normal business hours.

Refer to the Quick Start Guide for your type of Payment Gateway if you have any follow-on questions.

5c. Mobility Print

If PaperCut Mobility Print is installed on the same server as PaperCut, then there are a few steps you will want to do to migrate the application and your settings to the new server.

If Mobility Print is not installed or runs on a separate server like a Secondary Server, you can safely skip this section.

Steps:

1. Download PaperCut Mobility Print.
2. Install it on the new PaperCut server.
3. Copy and overwrite the entire contents of the folder [application-directory]/data/ from the old server to the new server. This folder includes configuration files that define a number of important details, such as whether specific printers are enabled or disabled, whether per-job authentication is turned on, rules to restrict printer access per subnet, and an authentication token. (On a 64-bit Windows server running PaperCut Mobility Print this would be C:\Program Files (x86)\PaperCut Mobility Print\data\).
4. Restart the new PaperCut server or Stop and Start the PaperCut Mobility Print Server serivce for the change to take effect.

Test and confirm: Log into the web interface of Mobility Print on the new PaperCut server and ensure the printers are published and the right discovery method (such as mDNS) is selected.

5d. Print Archiving

If your organization uses Print Archiving to retain a history of printed jobs then you may want to migrate your Print Archive.

If your organization does not Archive Print jobs, you can safely skip this section.

Steps:

1. Follow the instructions in the manual to install GhostTrap and enable Print Archiving per the instructions in the manual.
2. The next steps depend on whether your Print Archive is in the default location or you have created a Central Archive.
   • Default location: copy the files from the Archive directory, [application-directory]/server/data/archive to the same directory on the new server. (On a 64-bit Windows server running PaperCut MF this would be C:\Program Files\PaperCut MF\server\data\archive.)
   • Central Archive: (on a networked file share for example) follow the instructions in the manual so that the new server is configured to use the Central Archive.

Test and confirm: Try printing a job from your new print server. Confirm that a thumbnail for the job appears in the Job Log of PaperCut.

5e. Web Print

With a standard Web Print setup you shouldn’t need to do anything during the migration. However if your organization has Web Print Sandbox servers, you will want to disable the Web Print service on the main PaperCut server.

You should also be aware that Web Print Sandboxes will also communicate with the PaperCut server using a file share called the Hot Folder. If your organization moved the Hot Folder to a custom location, you may need to consult the manual section for the Web Print Sandbox. Confirm the share is set up with the proper permissions and that the Web Print Sandbox user is mapped to this file share.

Steps:’

1. Open services.msc by pressing Windows key + R, then type services.msc’ and hit the enter key.
2. Right-click on the PaperCut Web Print Server service, choose Properties, then set the Startup type to Disabled.
3. Make sure that the Web Print Hot Folder is correctly mapped for the logged in Web Print Sandbox user.
4. On the Web Print Sandbox, stop and then restart the Sandbox application.

Test and confirm: Try printing a job through Web Print. Confirm that the job prints out successfully.

5f. Print Deploy

If you are using Print Deploy to deploy print queues in your organization, follow the steps below.

Steps:

1. In the original server, navigate to the Print Deploy directory
   • Windows: [application-directory]/providers/print-deploy/win
   • macOS: [application-directory]/providers/print-deploy/mac
   • Linux: [application-directory]/providers/print-deploy/linux
2. Copy the entirety of the data folder
3. Go to the new server you’re migrating to and stop the Print Deploy server
4. Paste the data folder onto the same directory of Print Deploy in the new server, i.e., [application-directory]/providers/print-deploy/<os>. Overwrite any existing files.
5. Start the Print Deploy server

IMPORTANT: If the server you are migrating to has a different IP address or hostname from your original server, you will need to redeploy the clients with the new server’s hostname. We recommend that you redownload the client from your new server to ensure your clients are also up to date. Note that reinstalling or uninstalling the clients won’t remove the print queues already installed on your users’ computers; users can still print to all queues already deployed by Print Deploy.

Test and confirm: In the new server, log in to the PaperCut NG/MF page as an admin. Navigate to the Print Deploy tab of the Enable Printing section. Check that you can see your old zones and print queues in the interface. On a client’s machine, check that the Print Deploy client is now pointing to the new address of the server by opening [PaperCut Print Deploy Client app directory]/data/config/client.conf.toml. The key named ServerBaseURL should have been set to the new server’s hostname. If not, uninstall all the clients first and redeploy.

6. Inform users of the scheduled downtime for the migration

Let your users know before you begin that normal printing services will be unavailable during the scheduled period.

Users should also know any jobs currently in a Hold/Release or Find-Me printing queue will not be transitioned across to the new installation and they should release their jobs prior to the planned outage.

7. Migrate the database to the new PaperCut server

These exact steps will vary depending on whether PaperCut is configured to use the default built-in Derby database, or an external database (like SQL Server, PostgreSQL, Oracle).

If you intend for your PaperCut server to use an Internal Database then follow the steps on this page of the manual to export the database from the old server, then import the backup onto the new one.

If your PaperCut server will connect to your pre-existing External Database then follow these steps instead:

1. Stop the PaperCut services on the old server.
2. On the new server open the server.properties file in a plain text editor like Notepad.
3. Remove the # symbol from the beginning of the lines with the database connection details.
4. Save the file.
5. Next, restart the PaperCut Primary Application Server service on the new server for the change to take effect.

Test and confirm: After migrating your PaperCut Database following one of the above links, log into the web interface of your PaperCut server and check in the Job Log to ensure print history carried over successfully.

8. Power off the old server, or disable the network interface

Now that the data has been migrated successfully, you will want to make sure that users don’t keep printing to your old PaperCut server. Power off the old server or disconnect it from the network.

What if you’re not ready to power off the old server? Consider uninstalling PaperCut and converting it to a PaperCut Secondary Server. This way, if users are still printing through the old print server jobs will continue to be tracked by PaperCut.

Test and confirm: After disabling the network interface of your PaperCut server, try pinging this server from a separate workstation to be certain it is offline.

9. Post Migration Considerations

We recommend keeping the old PaperCut server for a few weeks even after a successful migration. If it turns out later that something wasn’t moved over correctly then it may be handy to keep this server for reference.

We’ve also heard of people keeping their old print server around but they turn it into a PaperCut secondary server, so that any clients still printing through the old print server will continue to have their jobs tracked. We love this idea, but think it only works when the old server gets to keep it’s IP address and hostname and the new server gets a new one. So, we’ll leave it up to you to decide if this is the right strategy for your environment.

Test and confirm: 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. For a checklist of testing steps, have a look at our Post Upgrade Test Plan.

Is there a video that shows me how to do this?

Yes! Have a look if you’d like to get a better understanding of how to perform a migration, but keep in mind this was recorded in 2016 – while this will show you the basics of the migration, it is still extremely worthwhile looking through the different sections above – including certificates, Mobility, payment gateways etc.

Running into trouble?

Let us know! We take pride in our documentation and want to make sure that it’s helping you to do your job. Feel free to leave a comment below or visit our Support Portal for further assistance.