> ## Documentation Index
> Fetch the complete documentation index at: https://docs.curator.interworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Moving Curator to a New Server

> End-to-end process for moving an existing Curator installation to new server hardware.

export const BackendNavPath = ({levelOne, levelTwo, levelThree, tab, section}) => {
  const levels = [levelOne, levelTwo, levelThree].filter(Boolean);
  const lastLevel = levels.length ? levels[levels.length - 1] : '';
  return <span>
      In the <a href="/site_administration/accessing_the_backend">backend of Curator</a> using the left-hand navigation,
      navigate to the
      {levelOne && <strong>{" " + levelOne}</strong>}
      {levelOne && levelTwo && " > "}
      {levelTwo && <strong>{levelTwo}</strong>}
      {levelTwo && levelThree && " > "}
      {levelThree && <strong>{levelThree}</strong>} page.
      {(tab || section) && <>
          {" "}On the {lastLevel} page
          {tab && <> click the <strong>{tab}</strong> tab</>}
          {tab && section && " and"}
          {section && <> expand the <strong>{section}</strong> section</>}.
        </>}
    </span>;
};

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.

<Note>
  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](https://interworks.com/help) rather than following this page.
</Note>

## 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](/upgrading_migration/migration/importing_and_exporting)** 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.

<Warning>
  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.
</Warning>

## Step 1: Install Curator on the New Server

Perform a normal fresh install on the new server using the guide for its operating system:

* [Windows Installation](/setup/installation/windows_installation)
* [Linux Installation](/setup/installation/linux_installation)

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.

<Note>
  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](/setup/installation/windows_installation) guide. See
  [IIS Installation](/setup/installation/iis_installation) for details.
</Note>

## 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.

<Warning>
  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.
</Warning>

1. <BackendNavPath levelOne="Settings" levelTwo="Curator" levelThree="Backups" />
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](/upgrading_migration/backups/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](/upgrading_migration/backups/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.

<Note>
  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.
</Note>

## 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.
2. <BackendNavPath levelOne="Settings" levelTwo="Curator" levelThree="Backups" />
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](/upgrading_migration/backups/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.
2. <BackendNavPath levelOne="Settings" levelTwo="Curator" levelThree="Backups" />
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](/upgrading_migration/backups/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](/server_management/system_administration/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](/site_administration/license_key/updating_license_key).

<Warning>
  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](https://interworks.com/help) to deregister the retired instance once the
  new server is confirmed working.
</Warning>

## 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](/server_management/system_administration/linux_cron_troubleshooting) or
  [Windows](/server_management/system_administration/windows_cron_troubleshooting).
* 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](/upgrading_migration/migration/saml_cutover) 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.