I have Aem version 6.4.x installed in the production environment and I should upgrade to version 6.5.x.
Reading the Adobe documentation it talks about duplicating the production environment and updating the duplicated environment.Is this just advice or the strategy to use?
In the referred documentation, when it says "exact production environment needs to be duplicated", the implicit meaning being that the upgraded environment should have the code, content, configs, users and customisations as your existing production environment so that there is no impact on your application after the upgrade.
However, the approach of upgrading will be your decision based on your project and many other factors, whether to go for in-place upgrade or start with the fresh instance.
In my organisation, we are in middle of upgrade and we chose to start with the fresh instance as there were a lot of obsolete packages and content which we didn't want to carry on in the new versions and we do not care about version history.
There are a lot of articles out there to plan for the upgrade, however this is the high level list that could be useful for the upgrade:
Points to be considered while upgrade
Run Pattern Detector
Fix the deprecated code / functionalities
Remove obsolete code
Cross check technical compatibilities with new version of AEM, for example version of ACS-Commons
Resolve Pattern detector issues
Classic UI Authoring – Classic UI authoring is still available in AEM 6.5 but is being deprecated. Plan for Touch UI migration accordingly.
Align with 6.5 Repository Structure (/etc)
Queries and Oak Indexes
Any use of queries in the code base needs to be thoroughly tested as part of upgrading the code base. If upgrading from an AEM 6.x version the out of the box Oak index definitions may have changed and could effect existing queries
Review OSGi configurations made from the Felix console
Review workflow modifications made from the AEM UI.
Determine ACLs and User Groups.
Review third-party integrations
Upgrade dispatcher version and associated configurations.
Before starting an upgrade, please make sure that your application codebase is stable and all the test cases will be executed as per the expected upgrade version.
Verify list of obsolete bundles uninstalled after the upgrade & make sure you contact Adobe Support and ask for a compatibility package for the affected area before upgrade , If your code relies on those bundles.
Migrate content from production to lower environments before testing the upgrade.
Create Run book for detailed implementation
Refer new AEM Core Components for any new components implementation
Test all OSGi services and external integrations.
Test all JCR queries
Test all APIs (Content APIs, other endpoints)
Test all AEM code overlays and tight integrations.
Test all web server (e.g. Apache) redirect and rewrite rules.
In the referred documentation, when it says "exact production environment needs to be duplicated", the implicit meaning being that the upgraded environment should have the code, content, configs, users and customisations as your existing production environment so that there is no impact on your application after the upgrade.
However, the approach of upgrading will be your decision based on your project and many other factors, whether to go for in-place upgrade or start with the fresh instance.
In my organisation, we are in middle of upgrade and we chose to start with the fresh instance as there were a lot of obsolete packages and content which we didn't want to carry on in the new versions and we do not care about version history.
There are a lot of articles out there to plan for the upgrade, however this is the high level list that could be useful for the upgrade:
Points to be considered while upgrade
Run Pattern Detector
Fix the deprecated code / functionalities
Remove obsolete code
Cross check technical compatibilities with new version of AEM, for example version of ACS-Commons
Resolve Pattern detector issues
Classic UI Authoring – Classic UI authoring is still available in AEM 6.5 but is being deprecated. Plan for Touch UI migration accordingly.
Align with 6.5 Repository Structure (/etc)
Queries and Oak Indexes
Any use of queries in the code base needs to be thoroughly tested as part of upgrading the code base. If upgrading from an AEM 6.x version the out of the box Oak index definitions may have changed and could effect existing queries
Review OSGi configurations made from the Felix console
Review workflow modifications made from the AEM UI.
Determine ACLs and User Groups.
Review third-party integrations
Upgrade dispatcher version and associated configurations.
Before starting an upgrade, please make sure that your application codebase is stable and all the test cases will be executed as per the expected upgrade version.
Verify list of obsolete bundles uninstalled after the upgrade & make sure you contact Adobe Support and ask for a compatibility package for the affected area before upgrade , If your code relies on those bundles.
Migrate content from production to lower environments before testing the upgrade.
Create Run book for detailed implementation
Refer new AEM Core Components for any new components implementation
Test all OSGi services and external integrations.
Test all JCR queries
Test all APIs (Content APIs, other endpoints)
Test all AEM code overlays and tight integrations.
Test all web server (e.g. Apache) redirect and rewrite rules.
@robertol6836527 From the documentation - "exact production environment needs to be duplicated" could mean just that in the production all applications and custom code still run as desired after all the changes are made.
It's always recommended to upgrade to the latest versions so as to make use of the latest features & updates and be current, However, you would have to consider it based on different factors including cost and time.
As 6.4.x is not so far off there wouldn't be an urgent need for an upgrade and could be planned accordingly.
Duplicating the production environment would allow parallel developments and upgrades without impacting the existing site and the business gets the freedom to use it as needed as per its stability could be a good strategy to use but not the only one. It could vary based on different parameters.
