Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

AEM as a cloud service migration

Avatar

Level 2

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

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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

View solution in original post

3 Replies

Avatar

Community Advisor

@subrahmanyamj 

 

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

Avatar

Community Advisor

@subrahmanyamj 

 

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

Avatar

Correct answer by
Community Advisor

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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