Upgrade PostgreSQL on Private Cloud from 9 to 14 - x360Sync

Written By Nikki Klukowski (Administrator)

Updated at March 24th, 2026

Overview

The recommended process for upgrading PostgreSQL on a Private Cloud server involves running versions 9.x and 14.x side-by-side, taking all services offline, performing a backup from the old server, restoring to the new server, then bringing services back online.

This results in downtime during the migration process, the length of which depends on the size of the database. A simple method to estimate downtime in advance is to perform the database backup while services are online (step 4 below). Double the time it takes to create the backup for a rough approximation of how long the backup-and-restore process can take. Do not use that backup for the actual migration.

Important: If you have questions regarding these steps or need assistance with upgrading, please contact Support.

For help on upgrading other versions of PostgreSQL, see: 

 

Instructions

Download the PostgreSQL Installer

Visit https://www.enterprisedb.com/downloads/postgres-postgresql-downloads and download the installer. 

  • PostgreSQL version 14 is recommended as it is what we currently run in our production environments.
  • For the purposes of this document, version 14 is assumed.

Run the PostgreSQL Installer

  • All default options are fine:
  • All components selected
  • Installation directory: C:\Program Files\PostgreSQL\14
  • Data directory: C:\Program Files\PostgreSQL\14\data
  • Port: 5433 (Take note in case this differs. It is needed later.)

When prompted for a password for the postgres user, use the password configured in the server's config.ini in the [portal] section. If a different password is used the server fails to connect.

Stop Services

Ensure the following services are stopped: Anchor Server, Anchor Celery, Apache.

Backup the Original Portal Database

Use pgAdmin III to backup the original portal database from the original server. 

  1. Open pgAdmin III.
  2. You should see both the original server and PostgreSQL 14 in the server list.
  3. Connect to the original server.
  4. Expand the list of databases.
  5. Right-click the portal database and select Backup...
    1.png
  6. For the Filename field, select a location to save the backup and name it portal.backup.
  7. Select Custom from the Format drop-down.
  8. Select UTF8 from the Encoding drop-down.
  9. Leave all other options as the defaults.
  10. Click Backup.
    2.png
  11. The backup process may take a while depending on the size of the database. It should finish with the line Process returned exit code 0.
    3.png
  12. When the backup completes, click Done and close pgAdmin III.

If Using PG Root Databases: Backup Roots Database

Complete the steps in this section only if you are using PG root databases. Skip this section if you are not using PG root databases. 

  1. Right-click the roots database and select Backup....
  2. For the Filename field, choose a location to save the backup and name it roots.backup.
  3. In the Format drop-down, select Custom.
  4. In the Encoding drop-down, select UTF8.
  5. Leave all other options as the defaults.
  6. Click Backup.
  7. The backup process may take a while, depending on the size of the database. 
  8. When the backup completes, click Done and close pgAdmin III.

Restore the Portal Database on the New Server

Use pgAdmin 4 to restore the portal database on the new server. 

  1. Open pgAdmin 4. If the following error occurs when attempting to open pgAdmin 4 then you need to install a supported version for your operating system: The procedure entry point discardvirtualmemory could not be located in the dynamic link library C:\Program Files\PostgresSQL\14\pgAdmin4\runtime\nw.dll.
    • Download pgAdmin 4 v6.21 from https://www.pgadmin.org/download/pgadmin-4-windows/ (Windows Server 2012 and above).
    • We recommend installing pgAdmin 4 v6.21 somewhere easy to find such as the Postgres12 directory: C:\Program Files\PostgresSQL\14\pgAdmin4.
  2. You may be prompted to set a master password for pgAdmin 4 the first time you open it. A password at this point is not required, however, you can set a password or click Cancel to ignore.
  3. Connect to the new server, named PostgreSQL 14 by default.
    Screenshot 2026-02-11 at 11.05.11 AM.png

Create the New Portal Database

  1. Right-click the server and select Create > Database...
  2. Enter portal for the Database name.
    Screenshot 2026-02-11 at 11.07.58 AM.png
  3. Leave all other options as the defaults.
  4. Click Save.

Restore the Portal Database to the New Server

  1. Right-click the new portal database and select Restore...
  2. In the Format field, enter Custom or tar.
  3. In the Filename field, select the portal.backup file you saved earlier.
  4. Leave all other options as the defaults.
  5. Click Restore.
    Screenshot 2026-02-11 at 11.15.58 AM.png
  6. The restore process may take a while depending on the size of the database. It finishes with Process failed.
    7.png

Confirm the Restore Completed as Expected

  1. Click View Processes.
  2. Click the document icon on the Restore row.
  3. You should see an error in the restore log pg_restore: error: could not execute query: ERROR schema "public" already exists.
    8.png
  4. Scroll to the end of the log and you should see pg_restore: warning: errors ignored on restore: 1.
    9.png

If Using PG Root Databases: Restore the Root Database to the New Server

Complete the steps in this section only if you are using PG root databases. Skip this section if you are not using PG root databases. 

  1. Right-click the server and select Create > Database...
  2. Enter roots for the Database name.
  3. Leave all other options as the defaults.
  4. Click Save.
  5. Right-click the new roots database and select Restore...
  6. In the Format field, enter Custom or tar.
  7. In the Filename field, select the roots.backup file you saved earlier
  8. Leave all other options as the defaults.
  9. Click Restore.
  10. The restore process may take a while depending on the size of the database. 
    Screenshot 2026-02-04 at 9.53.53 AM.png

If Using PG Root Databases: Correct Portal Database Entries

Complete the steps in this section only if you are using PG root databases. Skip this section if you are not using PG root databases. 

  1. Launch pgAdmin and connect to the restored Portal database running on a PostgreSQL 14 instance.
  2. Navigate to Databases > portal > Schemas > public > Tablesroot_db_location.
  3. Change the host to reflect the new server address.
  4. Change Port to 5433.
    Screenshot 2026-02-04 at 11.17.10 AM.png

Update the Server Config

  1. Open \Anchor Server\conf\config.ini in a text editor.
  2. Change the port entry in the [portal] section to 5433 (or the port value you chose during the PostgreSQL installation).
    [portal]
    host = localhost
    database = portal
    port = 5433
  3. Save.

Update the Web Config

  1. Open \Anchor Server\web\config.py in a text editor.
  2. Add the following line after the PORTAL_DB_NAME line (change the port number if a different one was used during the PostgreSQL installation).
    If config.py already has a value for PORTAL_DB_PORT, update it instead.
    PORTAL_DB_PORT = "5433"
  3. Save.

Stop Postgresql-9.x Service

In postgresql-9.x service properties, change Startup type to Manual.

Restart Services

Restart the following services: Anchor Server, Anchor Celery, Apache.

Verify the Application Works as Expected

Edit section

Troubleshooting

If the backup/restore does not complete as expected or services fail to restart or function as expected, revert to the original database server:

  1. Ensure the postgresql-9.x services is running.
  2. Revert the configuration changes.
  3. Restart services.

If services were brought back online and users created new organizations, accounts, roots, etc., reverting to the original database will lose those changes. Data in roots that existed before the migration would be unaffected. The risk can be mitigated by disabling public access to services before bringing them back online, verifying functionality, then allowing public access; for example, by using a firewall or changing the server and Apache config to only listen locally. That process may vary per environment and is outside the scope of this document.