AEM as a cloud service migration | Community
Skip to main content
subrahmanyamj
subrahmanyamj
Level 2
July 9, 2024
Solved

AEM as a cloud service migration

  • July 9, 2024
  • 2 replies
  • 1757 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by EstebanBustamante

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!

 

2 replies

aanchal-sikka
Community Advisor
aanchal-sikkaCommunity Advisor
Community Advisor
July 9, 2024

@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
    aanchal-sikka
    Community Advisor
    aanchal-sikkaCommunity Advisor
    Community Advisor
    July 10, 2024

    @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
    EstebanBustamante
    Community Advisor and Adobe Champion
    EstebanBustamanteCommunity Advisor and Adobe ChampionAccepted solution
    Community Advisor and Adobe Champion
    July 9, 2024

    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
      Terms & ConditionsAccessibility statement

      Loading footer...