Upgrade process - Alfresco Content Services - 23.4 - 23.4 - Ready - Alfresco - external

Use this procedure to upgrade from a previous version of Content Services using one of the supported installation methods. The process involves a new installation of the Content Services binaries and configuration, and an in-place upgrade of a copy of the repository.

1. Install the new version of Content Services.
   1. Shut down your existing instance.
   2. Back up your existing repository (alfresco-v.1) and the database.
      Backup of the repository can be skipped if using an alternative mechanism to guarantee restoration of the repository to its pre-upgrade state. For example, AWS S3 storage allows for restoration to a fixed point in time as long as soft deletes are enabled. For more information, see the Amazon S3 documentation on Enabling versioning on buckets.
      Note: Back up any configuration overrides from the <extension> directory.
   3. Install the new version (alfresco-v.2) into a different directory from the existing installation.
      For example, the new Alfresco installation will have the following settings:
      In alfresco-global.properties:

      dir.root=/alfresco-v.2/alf_data
      db.url=url<v.2>
      

      In solrcore.properties:

      data.dir.root:/alfresco-v.2/solr/myindexes
      

2. Validate the new 23.x installation to check that it’s working correctly.
   1. Configure the new installation with a new repository and database (not the existing one).
   2. Start the server and validate that the system works correctly.
3. Apply all customizations to the new 23.x installation:
   1. Stop the server.
   2. Tailor your installation by removing any unwanted applications.
   3. Modify applications.
   4. Install the required AMP files. See Install Alfresco Module Package.
   5. Don’t copy the files. Copy only the override settings, so that you won’t overwrite the new extension files in the upgraded version.
   6. Start the server.
      Monitor the startup log messages for information on the status of the upgrade. If any issues occur in the logs during startup, you’ll need to rollback the whole repository to fix the issue and then try again.
   7. Fully test your customizations and configuration by following Test after customizing upgrade.
   8. Stop the server.
4. Restore production data.
   1. Remove all the files and directories under the contentstore directory of the new installation. Also, delete the database.
   2. Delete the files in the two Solr alfrescoModels directories, and the indexes in the two directories (solr/workspace/ and solr/archive/) of the new installation.
   3. Restore the backup of the indexes, contentstore directory, files, and database from your previous installation into the new installation. See Restore production data.
   4. Start the server.
      If any issue(s) occur in the logs during startup, you need to rollback the whole repository to fix the issue(s) and then try again.
5. If you’re happy with the upgraded system, remove the old installation and repository.
6. (Optional) Note that multi-tenancy is not supported from Content Services 6.x and newer versions.
   If upgrading to the latest version from 5.2, then the existing multi-tenancy (MT) extension files are no longer relevant and must not be migrated to the new version. It’s recommended that you backup your existing MT files.
7. (Optional) Perform this step if you’re working in a clustered environment:
   1. Shut down all nodes in the cluster.
   2. Perform steps 1 to 5 on each additional node in turn, ensuring that each node starts fully before restarting the next one.
      You need to copy the database once only, as it’s upgraded by the first node that’s upgraded. The other nodes detect it’s been upgraded and skip the database upgrade step.
      CAUTION: In a clustered environment, when the cloned nodes are restarted with a cluster license, the nodes may try to join the existing production cluster, and point to a cloned database instead of the production cluster database. This can lead to corrupted data. This occurs because the cloned node contains the cluster id from production and tries to join that cluster. To avoid this problem, you should ensure any cloned nodes required for upgrade testing are network isolated from the production nodes.