Skip to main content
When the server hosting Curator reaches end of life, or you are moving to newer hardware, you do not migrate Curator in place. Instead you install Curator fresh on the new server, then restore a full backup taken from the old server over the top of it. This page sequences that process end to end and links out to the detailed guide for each step.
This page applies to Curator On-Prem, where you host and manage the server yourself. Full backups are not available on Curator SaaS, because InterWorks hosts and manages those instances. If you are on Curator SaaS and need to move your instance, contact support rather than following this page.

​
Choosing Between a Full Backup and an Export

There are two ways to move Curator content to another server, and they are not interchangeable.
  • Full backup and restore moves the entire database and web root, including content, users, settings, uploads, theme, and code. Use it when you are replacing a server and want the new instance to match the old one exactly.
  • Import/Export moves selected metadata only, such as content, navigation, and settings. Use it when you are seeding a separate environment, or moving content between two instances that both stay in service.
Moving to new server hardware is the first case, so the rest of this page covers the full backup and restore path.

​
Before You Start

Gather the following from the old server. You will need them later in the process, and some become harder to retrieve once the old server is decommissioned.
  • The contents of <web root>/config/database.php, specifically the database host, port, database name, username, and password. The new server needs its own working values, and you will compare the two sets in Step 4.
  • A copy of <web root>/.env. This file is not included in a full backup, and it holds the APP_KEY value that Curator uses to encrypt stored secrets. You will carry that key over to the new server in Step 3.
  • Your Curator license key. The key is stored in Curator’s database, so a full restore normally carries it across, but having it on hand avoids a support round trip if activation fails.
  • Any server-level configuration that lives outside Curator’s web root and is therefore not in the backup, such as SSL certificates, virtual host or site bindings, and firewall rules.
Keep the old server running and untouched until you have confirmed the new server is working. Curator’s full backups are stored on the same server as Curator by default, so decommissioning the old server too early can destroy the backup you are relying on.

​
Step 1: Install Curator on the New Server

Perform a normal fresh install on the new server using the guide for its operating system: Confirm you can reach the new instance in a browser and log in to its backend before continuing. Restoring over a broken install makes it much harder to tell whether a later problem came from the restore or the install.
Curator no longer supports new installations on IIS. If your old server runs IIS, install on Apache on the new server using the Windows Installation guide. See IIS Installation for details.

​
Step 2: Take a Full Backup on the Old Server

On the old server, take a fresh full backup so the restore captures the most recent state.
Stop write activity on the old server before taking this backup, and keep it read-only through the cutover in Step 6. That means no new content edits, no uploads, and no user or settings changes. Anything written to the old server after this backup exists only there, is not carried across by the restore, and is lost when the old server is decommissioned.
  2. Click Take New Backup.
  3. Watch the job to completion under Settings > Curator > Queued Processes.
  4. Once it finishes, copy the resulting full_backup_YYYYMMDD_HHMMSS.zip file off the server. It is written to the directory shown in Backup Location, which is <web root>/storage/temp by default.
See Curator Backup for more detail on the backup interface. If the built-in backup cannot run — for example the server is low on disk space or the job fails — build the archive by hand using Taking a Manual Full Backup.

​
Step 3: Carry Over the Encryption Key

Curator encrypts stored secrets, such as Tableau connection passwords, personal access token secrets, and Connected App secrets, using the APP_KEY value in <web root>/.env. That file is not part of a full backup, and a fresh install generates its own key. If you restore the old server’s database under the new server’s key, Curator cannot decrypt those secrets, and every affected connection has to be re-entered by hand. To keep the saved secrets working, put the old key in place before you restore:
  1. On the old server, open <web root>/.env and copy the full value of the APP_KEY line.
  2. On the new server, open <web root>/.env and replace the value of its APP_KEY line with the copied value. Change only that line. Leave the rest of the file, including any database connection values, as the new install set them.
  3. Restart Curator so the new key takes effect. On Windows, run stop.bat and then start.bat from the Curator install directory. On Linux, restart Apache or PHP-FPM.
  4. Confirm you can still log in to the new instance’s backend.
If the old server’s .env file is no longer available, you can still complete the move. Restore as normal, then re-enter the password or secret on each affected connection, starting with your Tableau, Power BI, or ThoughtSpot connection settings.

​
Step 4: Restore the Backup on the New Server

A full backup contains a database dump and a zip of the old server’s web root. Restoring it overwrites the new server’s database and files with the old server’s, which is what makes the new instance an exact copy.

​
If the Database Connection Details Differ

The web root in the backup includes the old server’s config/database.php, and the database dump is written for the old server’s database name. If the new server’s database host, port, name, username, or password differ from the old server’s, restoring the archive unmodified can leave Curator pointing at the wrong database, or at one it cannot reach. Curator checks for this before restoring and refuses to continue when the connection details in the backup do not work, with an error telling you to fix the database connection first. Curator can rewrite the connection details inside the archive for you:
  1. Place the full_backup_YYYYMMDD_HHMMSS.zip file in the new server’s Backup Location, which is <web root>/storage/temp by default.
  3. Find the backup in the list and click the wrench icon in the Actions column, labeled Fix database connection in this backup.
  4. Enter the old server’s database host, database name, database user, and database password. These are the values you gathered from the old server’s config/database.php in Before You Start. Curator already knows the new server’s values and substitutes them in.
  5. Click Queue Fix and confirm the prompt, then watch the job to completion under Settings > Curator > Queued Processes. The backup’s status in the list returns to Ready when the fix is done.
The fix unpacks both layers of the archive, replaces the old values in the database dump and in config/database.php, and repacks the backup under its original name, so it takes a while and needs a good deal of free disk space on the new server. If the fix job fails, or you prefer to edit the archive by hand, follow the Handling Different Database Connections steps in Manual Restoration of Curator Backup instead. If the connection details are identical on both servers, no fix is needed and you can restore the archive as it is.

​
Running the Restore

  1. Place the full_backup_YYYYMMDD_HHMMSS.zip file in the new server’s Backup Location, which is <web root>/storage/temp by default, if it is not there already. Curator only lists backups it finds in that directory.
  3. Find the backup in the list, identified by its timestamp, and click the Restore Backup icon, which is the counter-clockwise arrow in the Actions column.
If the restore fails for a reason you cannot resolve, restore the database and file system by hand using Manual Restoration of Curator Backup.

​
Fix File Permissions

Copying a web root between servers routinely leaves files owned by the wrong user, which shows up afterwards as cache, upload, or job system errors rather than as an obvious restore failure. Correct ownership on the new server using Filesystem Permissions.

​
Step 5: Reactivate the License on the New Server

Curator’s license key is stored in its database, so a full restore usually carries it over to the new server. Log in to the new instance and check Settings > Curator > System Upgrade to confirm the key is present and active. If the key did not carry over or fails to activate, re-enter it by following Updating License Key.
A standard license key covers up to 3 instances, with only one of them in Production. The old server still counts against that limit after you stop using it, so a server move can push you over the cap and cause activation to fail on the new server. Contact support to deregister the retired instance once the new server is confirmed working.

​
Step 6: Verify and Cut Over

Before pointing users at the new server, confirm the following on the new instance:
  • The portal loads and your content, navigation, and users all appear as they did on the old server.
  • Dashboards embed and render correctly. This confirms both that the restored connections to Tableau, Power BI, or ThoughtSpot still work from the new server’s network location, and that the encryption key carried over in Step 3 decrypts their saved credentials.
  • Scheduled tasks are running. If backups, exports, or other scheduled jobs never appear, work through the cron troubleshooting guide for Linux or Windows.
  • A new full backup completes on the new server.
If your portal authenticates through SAML, whether the identity provider needs changing depends on how you cut over. A DNS-only move, where the same public hostname now points at the new server and the SAML endpoints are unchanged, needs no identity provider changes. If the hostname or a SAML endpoint changes, the identity provider still points at the old values and must be updated as part of the cutover — follow SAML Cutover Process to sequence the DNS and SAML changes with minimal downtime. Once the new server is confirmed working and the retired instance has been deregistered, the old server can be decommissioned.