Learnings from cloud migrations (that can help you avoid headaches)
AEM as a Cloud Service is available for a while now, but moving from AEM 6.5 to AEMaaCS is still a thing for many customers.
In my talk, I will describe a few organizational patterns for cloud migration projects that turned out to be effective for us. Once a migration project starts, many challenges will be encountered.
I’ll present four of the more interesting challenges we had in real customer projects. Each finding provides interesting insight about how AEMaaCS and Cloud Manager are working under the hood – and each may cause headaches if you are on a tight timeline.
cziegeler
Which team is responsible for merging new features into the migration branch?
Masoud Rozati
I would say the migration team. But merge them only when they passed the QA of the 6.5 team
Thomas
The migration team. They need to understand what enters their responsibility, and have clarification with the 6.5 team if needed.
Amine
Can you share an advanced lesson or a unique challenge from your cloud migration experience that isn’t commonly discussed?
Thomas
The biggest challenges are when you face either removed product features (like reverse replication), or have implementation that is not considered good practice on AEMaaCS anymore (like binary processing or depending on a long livetime of publishing instances). For these, you often need re-implementation or a new architectural approach. It's also an option to think out of the box, no everything needs to be solved in AEMaaCS.
wolf
How do you propose to both implement the changeset "on 6.5", which lacks some of the libraries that are present in AEMaaCS - and not suppressing the warnings adding those libraries causes, because Adobe decided to be opinonated?
Henry Kuijpers
He was of course talking about the stuff that actually *was* already available in AEM 6.5; He was saying that you should try to get it already approved and present in the codebase of 6.5, so that you're not going to postpone finding issues during your cloud migration.
Thomas
I'm not sure if I understood the question. Feel free to talk to me during the breaks. There shouldn't be a flow of code/features from AEMaaCS codebase to AEM 6.5 codebase. During cloud migration, you will take a closer look at many parts of the application, and may notice bugs that have been in the application for a long time. Fixing them is not the focus of the migration project, it may even put a risk on your timeline. If business decides that these need to go, there are a few options (depending on the issue): - the 6.5 team takes care of them, and with that the fixes will get merged to the migration branch later on - put them in backlog, and fix after migration is done - won't fix - if they have been around for a while, they may not be that important.