Hi,
We have 5.56 CQ in our production system. We want to migrate from CQ 5.56 to AEM 6.2 .
We will do this process by inplace migration. It may take a day because of size of repository.
Problem:
1). We will have to shut down our CQ for a day. Is there any other alternate option for it so that it continue to give service .
Our Solution:-
Copy the Cq folder and perform the upgradation and when it complete swith to it.
But Problem in it if in between migration, Some changes occurs in Old CQ, which doesnot reflect in new AEM 6.2.
Any Concern?
Thanks
Solved! Go to Solution.
Hi,
when you say you can't have downtime are you talking about the publish tier or author tier? Usually it is important to avoid downtime on the publish tier.
Where is most of the time taken if you are saying it takes a day to do an upgrade?
There will be downtime required on the authoring tier, precisely because you cannot make changes to content while the upgrade is happening. You must shutdown the repository, even if you took a copy of the instance and performed the backup while the old author was running, It becomes difficult to sync any changes made from the old system to the new system, packages could be used, but the content structure could be changed during an upgrade and packages won't convert the old content to the new format, you would also lose versions in a package. There is also application state that can't be transferred, for example running workflows or jobs.
If you have one author and at two publish instance, what you can do is to do a cold backup of the author and one of the publish instances and then perform the upgrade on these instances. This means your publish tier can continue to server traffic while the upgrade happens, once the upgrade is complete and has been tested you can bring online the new publish instances. Continuing to have authoring changes while the system is upgraded is difficult.
Regards,
Opkar
Hi
The answer form experts are:
1. The update to a newer AEM version always requires restarts but of course you can arrange the update process in a way, that everytime at least 1 instance is up.
2. We can limit noticeable downtime with caching and a solid upgrade plan though, although if you cannot freeze authoring activity it becomes more complex.
I hope this would help you.
~kautuk
Hi,
when you say you can't have downtime are you talking about the publish tier or author tier? Usually it is important to avoid downtime on the publish tier.
Where is most of the time taken if you are saying it takes a day to do an upgrade?
There will be downtime required on the authoring tier, precisely because you cannot make changes to content while the upgrade is happening. You must shutdown the repository, even if you took a copy of the instance and performed the backup while the old author was running, It becomes difficult to sync any changes made from the old system to the new system, packages could be used, but the content structure could be changed during an upgrade and packages won't convert the old content to the new format, you would also lose versions in a package. There is also application state that can't be transferred, for example running workflows or jobs.
If you have one author and at two publish instance, what you can do is to do a cold backup of the author and one of the publish instances and then perform the upgrade on these instances. This means your publish tier can continue to server traffic while the upgrade happens, once the upgrade is complete and has been tested you can bring online the new publish instances. Continuing to have authoring changes while the system is upgraded is difficult.
Regards,
Opkar