Choose your language

Choose your login

Contact us

Migrating or Moving your PaperCut Database Server

THE PAGE APPLIES TO:

“I need to move my PaperCut database to a different server - how do I do that?”

If you’re running PaperCut on an external database like Microsoft SQL, PostgreSQL, MySQL or Oracle, chances are that at some point you’ll need to move it. If you’re looking to migrate your external PaperCut database to a new server, this is the guide for you!

If you’re currently running on the default PaperCut ‘Derby’ database (check under About → Systems Info, in the PaperCut admin interface to check what you’re using currently), and you want to upsize to an external DB, head on over to the Upsize to an external database help center article.

Note: This article is not describing how to move or migrate your PaperCut Application server. That is described over on the article: Migrating PaperCut to a new server (when using an external database)

Your Options

The PaperCut App Server doesn’t really mind where the data is that it’s using - as long as it knows the host of the database, and connection details. So when it comes to migrating your database, it’s pretty forgiving as to how you want to do it.

There are two main options:

  1. Use PaperCut tools to perform the migration - basically using PaperCut to export the data from the old database, and then import the data into the new database.
  2. Use your database tools of choice to perform the migration - for example the database team at your organization might have preferred methods for moving databases from one server to another. In which case, it’s just a matter of re-pointing PaperCut to the new database server.

Using PaperCut Tools

In this method, you’ll use the PaperCut ‘db-tools’ utility to move the data from the old database to the new database.

Follow the steps in the Upsize to an external database checklist. The summary of the steps is below:

  1. Stop the PaperCut NG/MF Application Server
  2. Perform a backup of the existing data (from the old database)
  3. Create a new database in the external RDBMS (the new database)
  4. Configure the database (the new database)
  5. Change the PaperCut NG/MF connection details (to point from the old database to the new database)
  6. Initialize the new database
  7. Load the data into the new database
  8. Restart the PaperCut NG/MF Application Server
  9. Test!

Hang on, that seems too simple - why does that work?

In the same way that when you moved from the internal derby database to an external database, you’re doing exactly the same thing moving from one external database to another - so the steps are identical.

Using your own Database Tools

If you have a large set of databases running across multiple SQL servers, chances are that you have a database team looking after them. They’ll want to use their own processes and tools to move data around - just like any other database that they’re maintaining.

Again, you can follow the steps in the Upsize to an external database checklist. However - some of the steps will effectively get performed by your database team. The summary of the steps is below:

  1. Stop the PaperCut NG/MF Application Server
  2. Database team will perform the database migration:
    1. Backup the old database
    2. Create the new database
    3. Configure the new database
    4. Copy all the data from the old database to the new database
  3. Change the PaperCut NG/MF connection details (to point from the old database to the new database)
    1. Note that you don’t need to perform the ‘Initialize the new database’ or ‘Load the data’ steps since the new database is already loaded with the migrated data.
  4. Restart the PaperCut NG/MF Application Server
  5. Test!

Still have questions?

Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.


Categories: How-to Articles , Databases


Keywords: migrate database , move database , sql migration , oracle migration , sql express migration , postgresql migration

Comments

Last updated February 15, 2024