Upgrade 6.2 to 6.5

[Mani_kumar_]

Hi All,

If we want to upgrade AEM from 6.2 to 6.5 what is best approach(upgrade to new instance not inplace) for /content and dam migration.

I was trying with oak.jar upgrade with including necessary path /content/projectcontent and /content/dam/projectcontent.

Will this approach of oak-upgrade.jar works for 6.2 or it is recommended only for 6.3 and above versions.

Thanks in advance.

[Jaideep_Brar · Accepted solution]

Yes, oak-upgrade can be used for 6.2 to 6.5 migrations. See [1] for basic setup and commands:

[1] https://medium.com/@bikkurthi/offline-content-migration-in-aem-using-oak-upgrade-b23baa395eb8

[Mani_kumar_]

Thanks for the response.

[Mani_kumar_]

Is this possible to lower to higher with versions and timeline history ?

[Mani_kumar_]

Thanks for the response.

It says both needs to be same version is it mandatory or lower to higher version is also possible ?

If possible then i also need to migrate the versions and timeline history on pages and dam is this can be achievable from this ?

[Jaideep_Brar]

The same version is only for that example shared above. It can be used to move from lower to higher version without issues

[markus_bulla_adobe]

Hi @Mani_kumar_!

There are different approaches to upgrade from older AEM versions to newer ones.

• In place upgrade - basically stopping your instance, replacing the quickstart.jar with the newer version and starting it again.
• Upgrade to a new environment - setting up a new environment with the target version and migrating your project (content, code, configurations, etc.) to that new environment.

From my experience the most reliable and clean way is a combination of these two approaches:

• Setup a new, clean environment with the target version.
• Perform an in-place upgrade on the old environment.
• Migrate everything from the old to the new instance (e.g. using the crx2oak tool).

The upgrade process includes rewriting/relocation/transformation of certain elements in the content. This step may get lost if you just migrate your content from an old 6.2 or 6.3 instance to a new 6.5 environment using a content migration tool, such as crx2oak.

Apart from the "pure" instance upgrade/migration, please also consider the following tasks that make sense and/or are necessary for an upgrade:

• Upgrade your JRE to the latest supported version. AEM 6.5 supports Java 8 and 11.
• Make sure to include the latest Service Pack on the target version (SP 8 for AEM 6.5).
• Perform some clean-ups and grooming on your repository before migration. Get rid of everything that is no longer needed, execute the common maintenance tasks (workflow and version purge) and run a repository compaction.
• Upgrade your projects dependencies (primarily the uber-jar).
• Refactor your code to ensure it's functioning as expected under the new version and with the new dependencies.
• Consider upgrading any 3rd party libraries, integrations and similar to their respective latest versions as well.
• Consider some code refactoring work to follow the latest recommendations and best practices, avoid usage of deprecated APIs/features/etc. and make your code base as modern, clean and up-to-date as possible.
• Consider automating the provisioning and configuration of your AEM environments.

Please also note: the bigger the upgrade version step, the more work it is. So plan to test the actual migration process, ideally on a production clone to ensure that you are comfortable with it and there are no surprises during the actual migration run.

Please also refer to these documentations:

• Planning your upgrade
• Upgrading to AEM 6.5

Hope that helps!

[Mani_kumar_]

Thanks for the above points Marcus. We have completed the code related changes and also tried upgrading the jar directly from old to new instance using oaktool but i see repository is reduced is this expected ?

[markus_bulla_adobe]

It's hard to say without detailed knowledge, but it is not uncommon that the repository is smaller after migrating to a new, fresh instance. One step that I missed to mention in my initial post is that as a pre-work it is usually recommended to cleanup everything no longer needed from the old instance (e. g. old packages) and run the according maintenance cleanup jobs (workflow and version purgen, compaction) to reduce the repositiory size. This will help with a smoother migration and speed up the actual upgrage/migration. Coming back to your question: it is not uncommon that the repository is smaller after such a migration. You may have left older versions out of the migration, you probably did not migrate old workflow instances, old packages, etc. However, you will have to double check in your quality assurance if anything is missing after the upgrage/migration.