The upgrade will require downtime for the Author tier as most AEM upgrades are performed in-place. By following these best practices, Publish tier downtime can be minimized or eliminated.
When upgrading your AEM environments, you need to consider the differences in approach between upgrading author environments or publish environments in order to minimize downtime for both you authors and end users. This page outlines the high level procedure for upgrading an AEM topology currently running on a version of AEM 6.x. Since the process differs between author and publish tiers as well as Mongo and TarMK based deployments, each tier and microkernel has been listed in a separate section. When executing your deployment, we recommend first upgrading your author environment, determining success, and then proceeding to the publish environments.
The assumed topology for this section consists of an Author server running on TarMK with a Cold Standby. Replication occurs from the Author server to the TarMK publish farm. While not illustrated here, this approach can also be leveraged for deployments that use offloading. Make sure to upgrade or rebuild the offloading instance on the new version after disabling replication agents on the Author instance and before re-enabling them.
Stop content authoring
Stop the standby instance
Disable replication agents on the author
Run the pre-upgrade maintenance tasks.
Run the in-place upgrade
Update the dispatcher module if needed
QA validates the upgrade
Shutdown the author instance.
Copy the upgraded instance to create a new Cold Standby
Start the Author instance
Start the Standby instance.
Start the Cold Standby instance as the new Primary
Rebuild the Author environment from the Cold Standby.
The assumed topology for this section consists of a MongoMK Author cluster with at least two AEM Author instances, backed by at least two MongoMK databases. All Author instances share a datastore. These steps should apply to both S3 and File datastores. Replication occurs from the Author servers to the TarMK Publish farm.
DocumentNodeStoreService.cfgfile on the primary Author to reflect your single member replica set
Create new 6.5 Author instances, connected to the upgraded Mongo instance
Rebuild the MongoDB nodes that were removed from the cluster
DocumentNodeStoreService.cfg files to reflect the full replica set
Restart the Author instances, one at a time
Remove the cloned data store.
Reconfigure the secondary Author instances to connect to the cloned data store
Shut down the upgraded Author primary instance
Shut down the upgraded Mongo primary instance.
Start up the secondary Mongo instances with one of them as the new primary
DocumentNodeStoreService.cfg files on the secondary Author instances to point to the replica set of not yet upgraded Mongo instances
Start up the secondary Author instances
Clean up the upgraded author instances, Mongo node and data store.
The assumed topology for this section consists of two TarMK publish instances, fronted by Dispatchers that are in turn fronted by a load balancer. Replication occurs from the Author server to the TarMK Publish farm.