---
title: Replication server
description: This page shows how to upgrade a standalone replication server in place. A standalone replication server has no local user data. If the server holds user data, refer to Directory server instead.
component: pingds
version: 7.4
page_id: pingds:upgrade-guide:upgrade-rs
canonical_url: https://docs.pingidentity.com/pingds/8.1/upgrade-guide/upgrade-rs.html
llms_txt: https://docs.pingidentity.com/pingds/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: 2023-08-10T15:45:40Z
keywords: ["LDAP", "Replication", "Upgrade"]
superseded_by: https://docs.pingidentity.com/pingds/8.1/upgrade-guide/upgrade-rs.html
---

# Replication server

This page shows how to upgrade a standalone replication server in place. A standalone replication server has no local user data. If the server holds user data, refer to [Directory server](upgrade-ds.html) instead.

If you are adding a new server to an existing deployment, refer to [When adding new servers](add-new-servers.html) instead.

|   |                                                                                                                                                                                          |
| - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | Before upgrading, make sure you stop the server. Once you have unpacked the new server files, do not modify the server configuration until after you have completed the upgrade process. |

1. Prepare for upgrade as described in [Before you upgrade](before-you-upgrade.html).

2. Stop the server.

3. Proceed to upgrade the server:

   1. When upgrading a server installed from the cross-platform ZIP distribution:

      * Unpack the new files over the old files as described in [Unpack files](../install-guide/install-files.html).

      * Run the [upgrade](../tools-reference/upgrade.html) command to bring the server up to date with the new software delivery.

        By default, the `upgrade` command runs interactively, requesting confirmation before making important configuration changes. For some potentially long-duration tasks, such as rebuilding indexes, the default choice is to defer the tasks until after upgrade.

        You can use the `--no-prompt` option to run the command non-interactively. In this case, the `--acceptLicense` option lets you accept the license terms non-interactively.

        When using the `--no-prompt` option, if the `upgrade` command cannot complete because it requires confirmation for a potentially long or critical task, then it exits with an error, and a message about how to finish making the changes. You can add the `--force` option to force a non-interactive upgrade to continue in this case, also performing long-running and critical tasks.

   2. When upgrading a server installed from native packages, use the system package management tools.

   Although unlikely, when the server configuration has changed in an incompatible way with the previous release, the `upgrade` command can fail when performing property value substitution for a configuration expression. If this happens, change the configuration to a static value during upgrade. Use the configuration expression again after you successfully run the `upgrade` command.

4. Start the upgraded server.

   At this point, the upgrade process is complete. Refer to the resulting `upgrade.log` file for a full list of operations performed.

5. If you disabled the Windows service to upgrade, enable it again:

   ```powershell
   C:\path\to\opendj\bat> windows-service.bat --enableService
   ```