AEMaaCS author sites interface customization

[SHVR]

Recently we have come across a requirement to migrate an application from AEM6.3/6.4 to AEMaaCS.

Existing application has heavy customization done to the site's navigation. Three levels of navigation from sites interface. 

Let's say

Level 1 > Tools,

Level 2 > Tool1 till Tool 6

Level 3 > each tool has different set of functionalities

It is safe to assume that the dashboard has 15+ functionalities and few of the functionalities depend on the other functionalities. 

We are seeing two options 

1. Replicate the dashboard in AEMaaCS and keep track of the dashboard in the subsequent updates

2. Create utility pages and port the dashboard functionality instead of customizing the dashboard. 

Is it recommended to port the same dashboard from old AEM to AEMaaCS author instance? Is it even recommended to do so given the automatic feature and maintenance updates in lower environments in the AEMaaCS. 

[TarunKumar]

Hi @SHVR ,

You can try to create utility pages and port the dashboard functionality. There might be some other changes you will have to do based on where the data which are residing in etc, content or apps folder. of CRX.
Can also try to take reference from below link

https://experienceleague.adobe.com/en/docs/experience-manager-guides/using/install-guide/cs-ig/migra...

-Tarun

[SHVR]

Just FYI, it looks like you shared a link to migrate the guides content, my query is more related to sites (Author instance) customization.

[SHVR]

Thanks for the reply @TarunKumar 

But is it recommended to port the same dashboard from old AEM to AEMaaCS author instance? Any documentation around the suggestion like not to customize the dashboard or can be customized with some caveat?

[AmitVishwakarma]

It’s not recommended to port the same custom dashboard from AEM 6.x directly to AEMaaCS due to potential compatibility and maintenance challenges. AEMaaCS has a different architecture, and its automatic updates could break custom features tied to legacy code.

Recommended Approach:
1. Rebuild the Dashboard as Utility Pages:
          - Break down the existing dashboard into modular utility pages. This approach is better suited for AEMaaCS’s cloud-first infrastructure and supports easier maintenance with automatic updates. 

         - Use AEM’s headless CMS capabilities and APIs for dynamic data, ensuring scalability and flexibility.

Advantages of Utility Pages:
        - Future-proof: Utility pages are easier to update and maintain.
        - Scalable: Modular design allows for independent updates without affecting the entire dashboard.
         - Cloud-native: Aligns with AEMaaCS’s cloud-based architecture, reducing risks with updates.

Customization Caveats:
           - Porting the entire legacy dashboard may require constant refactoring due to AEMaaCS’s evolving features.
           - Focus on modern AEM components and cloud-native best practices for more seamless integration.

[kautuk_sahni]

@SHVR Did you find the suggestions helpful? Please let us know if you need more information. If a response worked, kindly mark it as correct for posterity; alternatively, if you found a solution yourself, we’d appreciate it if you could share it with the community. Thank you!