AEM upgrade - fresh install

[Nitiks25]

For upgrade, instead of following the steps given in the documentation (https://docs.adobe.com/docs/en/aem/6-2/deploy/upgrade.html), will it be enough if we just launch a fresh instance of the new version and package and install our application content (content, configurations, bundles, etc.) into the new version.

Will any of the upgrade steps still have to be executed if we are going this route? Also, will repository migration (crx2oak) be required in this case?

Any pros and cons that you are familiar with for such an approach?

Thanks

[MaxBarrass]

If you want to do InPace upgrade then you need to follow that.

If you can install packages to a new instance might as well do that instead, you could do AEM6.3 as well

[Hemant_arora]

Hi,

If you do inplace upgrade, you dont need to deploy your content/packages or bundles etc. You dont need to reconfigure any custom authentication or any other configuration you did in the older version like logging or schedulers etc.

so inplace upgrade will save a lot of effort.

if you do a fresh install of aem 6.x version, you need to deploy everything again.

You need to migrate the repository only in case you are upgrading from AEM 5.6.1 to 6.1/6.2/6.3

if you are already on 6.1 ,no need to upgrade repo., you just need to run 2 commands and its done.

choice is urs, 2 commands or 20 commands.

Few advantages,

a) Fresh instance without any orphaned version histories (GB's of data under /jcr:system/jcr:versionStorage)

b) No worries on the versions of the bundles which would not get upgraded and will stay as only installed state.

c) No chance of old legacy corrupted nodes continuing to stay in the upgraded instance, since this will be brand new.

d) Avoiding any extra manual steps which are involved in cleaning up of few files from the launchpad location as documented in my in place upgrade blog.

e) Lesser chance of indexes getting corrupted.

[Opkar_Gill · Accepted solution]

Hi,

the way upgrade process is tested internally at Adobe is by doing in-place upgrades. In this way you ensure the software and content is upgraded and it is the recommended approach

If you decide to use content packages (advised by daycare because of particular issues), then the migration of content structure or post upgrade tasks will not be run on your content. You can't migrate version history or orphaned objects with packages. If you want to migrate just the content to the new instance, you should use CRX2OAK rather than content packages.

Regards,

Opkar

[Nitiks25]

Thanks Opkar

since we are upgrading from 6.0 to 6.2 and it may have been using OAK in that case is there a need to use CRX2OAK tool?

[Nitiks25]

Thanks a lot Hemant

If I may, could you please elaborate on the '2 commands' you've mentioned in your post.

[sureshr19072451]

Thanks Hemanth..

It would be helpful if you provide those two commands. Please also consider external datastores as well.