This information will be useful if you are planning to upgrade your CQ environment to CQ5.5. This information is intended as a supplement to the official upgrade documentation: http://dev.day.com/docs/en/cq/current/deploying/upgrading.html
You should read these recommendations, and then follow the steps in the upgrading documentation, applying the added suggestions here as required.
It’s better to first run a dry-run migration on a clone of UAT (author & publish instances) to ensure that there are no major issues in the upgrade process. Check if there are any changes needed for your code to work on the upgraded version. In this case, change the code and ensure you have a consistent process for applying those changes. Identify any high risk areas in the code and plan for extended testing time on these areas following the upgrade. Repeat the steps from scratch on the UAT clone so that you’ll be sure to have a consistent end-to-end process for the upgrade. Then proceed to upgrade all the environments: DEV, UAT & PROD.
- Create a clone of the instance to upgrade. You’ll perform the upgrade on the clone. It will be easier to rollback in case of problems.
- Perform a full consistency check on the repository early. Fix any problems before attempting the upgrade/migration.
- Read the extensive list of “Tips and Troubleshooting” in the upgrade documentation and apply the recommended changes to avoid these common problems.
- The code-base has to be frozen before the upgrade process and all the existing bugs closed. In case it’s not possible to close all bugs, keep a detailed list of them and double check them on the upgraded version.
- Only do 1:1 migrations. Only introduce new product features for editors/business later. This will let you focus on the migration itself and any regressions.
- Try to get dedicated hardware for all environments (PROD + staging), this gives you much more flexibility.
- Involve Adobe consulting if required. This will ensure a smooth migration process adhering to best practices.
- Compile a list of all connected systems and involve those teams in the migration planning. Ensure they have a short turn-around time in case of issues.
- Purge workflow history (this speeds up the update process).
- Make sure all workflow tasks are finished (none are running).
- Make sure you have at least 1024MB Heap configured during update.
- Clean all the logs to make it easier to isolate upgrade issues.
Tests should cover complete authoring workflows and not just the correct rendering of templates.
Check ACLs and permissions (especially when updating from 5.2.1).
Check Workflow models – check if any customizations were overwritten.
Check all forms and form actions (especially when updating from 5.3 or older).
After performing the upgrade process on a UAT instance, once you are ready to upgrade the production instances, there shouldn’t be any major/unexpected issues. The code-base should already be frozen and in a good state, and you should freeze out content changes also. Only urgent changes should be applied to the content and the author team will need to keep track of all updated pages. These can then be moved later with a package.
1. Follow all the steps documented in the upgrade docs.
2. Sign-off the environments.
3. Migrate the latest content changes (if needed).
4. Switch the instances.
5. Delete all the dispatcher(s) cache.
It’s better to keep the old instances available for a while in case of problems not encountered during all the documented steps. You should plan enough time for bug fixing following the production upgrade.