SOLVED
AEM as a cloud service migration
1 Accepted Solution
Correct answer by
Hi,
These are my two cents, and please take them as my personal advice. First of all, while the number may look scary, I'm sure many of those instances will be the same mistake repeated. I think diving deep into the report might give you a better idea of the actual workload. Now, addressing your questions:
-
Several things could happen if you don't fix the issues. Perhaps the main problem you could face is incompatibility; Adobe does not support code that does not meet their standards. If any issues arise, you'll be left to resolve them alone. Another potential consequence is that your code could be detrimental to AEM as a Cloud Service (AEMaaCS) instances, leading to additional resources and costs. At any point, Adobe might identify your code as the cause of issues and require you to upgrade it.
-
I think technically static templates could live in AEMaaCS, however, as you know these are considered a "bad practice" since AEM 6,5, and that's why AEM Modernizer tools ship a specific tool to migrate from Static to Editable Template. I think you should give it a try and see how this conversion will go. Additionally, having 60 static templates alongside 30 editable templates seems excessive. Perhaps these are remnants from an old implementation, and cleaning them up should be your first step in migration.
-
Yes, you could definitely encounter performance issues. As I mentioned earlier, compatibility issues or unsupported code patterns in AEMaaCS could lead to bottlenecks. I'm less certain about security issues.
-
It's hard to predict exactly what could happen, but I believe proceeding as-is carries risks. I've elaborated on this point somewhat in my response to question 1.
My final advice is to take advantage of the tools Adobe provides for migrating older components, such as the AEM Modernizer Tools and the Dispatcher Converter. Understanding how much you can reduce your scope by leveraging these tools is crucial.
Hope this helps!
Esteban Bustamante
Critical issues will need to be addressed
| Importance | Description |
|---|---|
| INFO | This finding is provided for informational purposes. |
| ADVISORY | This finding is potentially an upgrade issue. Further investigation is recommended. |
| MAJOR | This finding is likely to be an upgrade issue that should be addressed. |
| CRITICAL | This finding is very likely to be an upgrade issue that must be addressed to prevent loss of function or performance. |
For major, please address as needed. But, please do resolve them over time.
- Verify related functionalities on Cloud instances.
- Resolve the blockers that you might encounters in Cloud manager pipelines.
- Code coverage will need to be atleast 50%.
Aanchal Sikka
I second all the suggestions made by @EstebanBustamante
Just adding few more points.
- Fixing everything would not be possible. So, prioritize and resolve. Especially critical and blockers.
- Validate all the functionalities that use long-live sessions. Fine-tune them into short-live sessions.
- Validate event based functionalities. Use Sling jobs wherever possible.
- If using custom asset workflows, evaluate them for Cloud architecture.
- Refactor dispatcher code as per Cloud recommendations
- For any new functionality follow AEM Cloud recommendations.
- Use Editable templates for new sites. Gradually migrate all static to editable templates.
Aanchal Sikka
Correct answer by
Hi,
These are my two cents, and please take them as my personal advice. First of all, while the number may look scary, I'm sure many of those instances will be the same mistake repeated. I think diving deep into the report might give you a better idea of the actual workload. Now, addressing your questions:
-
Several things could happen if you don't fix the issues. Perhaps the main problem you could face is incompatibility; Adobe does not support code that does not meet their standards. If any issues arise, you'll be left to resolve them alone. Another potential consequence is that your code could be detrimental to AEM as a Cloud Service (AEMaaCS) instances, leading to additional resources and costs. At any point, Adobe might identify your code as the cause of issues and require you to upgrade it.
-
I think technically static templates could live in AEMaaCS, however, as you know these are considered a "bad practice" since AEM 6,5, and that's why AEM Modernizer tools ship a specific tool to migrate from Static to Editable Template. I think you should give it a try and see how this conversion will go. Additionally, having 60 static templates alongside 30 editable templates seems excessive. Perhaps these are remnants from an old implementation, and cleaning them up should be your first step in migration.
-
Yes, you could definitely encounter performance issues. As I mentioned earlier, compatibility issues or unsupported code patterns in AEMaaCS could lead to bottlenecks. I'm less certain about security issues.
-
It's hard to predict exactly what could happen, but I believe proceeding as-is carries risks. I've elaborated on this point somewhat in my response to question 1.
My final advice is to take advantage of the tools Adobe provides for migrating older components, such as the AEM Modernizer Tools and the Dispatcher Converter. Understanding how much you can reduce your scope by leveraging these tools is crucial.
Hope this helps!
Esteban Bustamante
Related Conversations
