Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Adobe Aem - CMS update to version 6.5

Avatar

Level 4

Good morning,

 

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?

 

Thanks

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @robertol6836527 ,

 

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.

  • Plan Security test

  • Plan Performance test

  • Plan Analytics test

View solution in original post

4 Replies

Avatar

Employee Advisor

@robertol6836527 

Can you please share the documentation you are referring?

Also, is it an In-place Upgrade?

Avatar

Correct answer by
Community Advisor

Hi @robertol6836527 ,

 

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.

  • Plan Security test

  • Plan Performance test

  • Plan Analytics test

Avatar

Community Advisor

@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.