Hello Community Team,
My current application is running on AEM 6.5 managed by Adobe (Adobe Managed Services). We are plannint to migrate the current application to AEM as a cloud service. As part of this exercise, we ran the BPA tool against the current application and encountered around 400 Critical bugs and 14000 Major bugs. There are 400 custom components, 60 static templates and 30 editable templates. Customer is looking to migrate as-is from AMS to AEMaaCS with minimal code changes in 3-4 months of duration.
Can you please suggest me the following:
1. Without fixing all the major and critical bugs reported by the BPA tool, is it recommended to migrate to AEMaaCS. If we still migrate, what could be the possible issues that may occur.
2. Will static templates work as-is in the AEMaaCS platform or we need to refactor them.
3. What could be the performance and security related issues that might occur with as-is migration
4. Any other issues that we may encounter if we go with as-is migration
Solved! Go to Solution.
Views
Replies
Total Likes
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!
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.
I second all the suggestions made by @EstebanBustamante
Just adding few more points.
Views
Replies
Total Likes
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!