This page shows how to upgrade a directory server in place.
If you are adding a new server to an existing deployment, refer to When adding new servers 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.
Failure to follow the upgrade instructions can result in the loss of all user data.
Prepare for upgrade as described in Before you upgrade.
Stop the server.
Proceed to upgrade the server:
When upgrading a server installed from the cross-platform ZIP distribution:
Unpack the new files over the old files as described in Unpack files.
Run the upgrade command to bring the server up to date with the new software delivery.
By default, the
upgradecommand 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-promptoption to run the command non-interactively. In this case, the
--acceptLicenseoption lets you accept the license terms non-interactively.
When using the
--no-promptoption, if the
upgradecommand 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
--forceoption to force a non-interactive upgrade to continue in this case, also performing long-running and critical tasks.
When upgrading a server installed from native packages, use the system package management tools.
When the mutable data mounted at runtime differs from that of the instance where you first run the
upgradecommand, upgrade only mutable data by running the command again with the
--dataOnlyoption at runtime.
--dataOnlyoption can be useful when running the server in a Docker container, for example.
This improvement is available when upgrading from DS 6.0.0 or later releases.
Start the upgraded server.
At this point, the upgrade process is complete. Refer to the resulting
upgrade.logfile for a full list of operations performed.
Replication updates the upgraded server with changes that occurred during the upgrade process.
When you upgrade from OpenDJ 3.0, the upgrade process leaves the HTTP connection handler disabled.
The newer REST to LDAP configuration is not necessarily compatible with the previous configuration. You must rewrite your configuration according to REST to LDAP reference, and then configure the server to use the new configuration.
If you disabled the Windows service to upgrade, enable it again:
C:\path\to\opendj\bat> windows-service.bat --enableService