Migration to AEM as a Cloud Service – the plan

Migration to AEM as a Cloud is a big undertaking and you have to think about it as a full-fledged, rather complicated project. It is worth starting (according to Adobe’s recommendations) with a good diagnosis of the current situation, estimation and finally building a project plan. As the issues in this area are very extensive, I have prepared a few questions and tips that will help you go through stage 1.

Cloud Manager

1. What are our sites? What integrations, with what systems do we have?
2. What does our current architecture look like – are there any non-standard, non-AEM elements?
3. What components (other than AEM) from the Adobe Experience Cloud do we use?
4. What is the Software Development Cycle like today? (From developer’s machine to Production). Would we like to change something about it?
5. Are there any external entities involved in the process? eg Who is involved in testing security, accessibility, performance, audits?
6. Based on the above two – what is missing in Cloud Manager and what can we reuse?
7. Where are we when it comes to the requirements of Quality Gates? eg code coverage (min 50%) with tests, static code analysis.
8. Are there any elements that are missing from Cloud Manager that we cannot start using without? (example: it is not possible to download dependencies from publicly unavailable sources)
9. Designing a solution combining your current Pipelines and Cloud Manager to maximize the use of the latter while maintaining our standards.
10. What will our software development cycle look like after implementing the above solution? What non-obvious consequences will appear (e.g. extension of deployment time due to the use of Cloud Manager)? How will developers work?
11. Which environments will Cloud Manager cover? How do we handle other environments?
12. How will entering the Cloud Manager world affect our DevOps? How will we respond to mistakes? Who will be responsible for what?

Code preparation

1. What AEM functionalities do we use in our components, workflows and code? (sending an email, rendition workflows, reverse replication, etc.) – it would probably be best to make a matrix that summarizes the current state on each site. Later, this will be useful for reviewing items that are not working in the Cloud version.
2. Do we use external libraries (e.g. ACS Commons)? If so, is this version compatible with AEMaacs?
3. What mvn archetype are you using? Is it compatible with Cloud?
4. As for the configuration of the Dispatcher – are we using any elements that will not work in the Cloud version? (eg SSI)
5. Run-on current BPA (Best Practices Analyzer) and generate a report.
6. Report analysis and a rough estimate of how long it will take us to adapt the code to the Cloud version.

Tests

1. What is our current testing status? Do we have any baseline? What tests do we have and what more would we like to have?
2. How do we validate after migration if the application is still working?
3. Do we have performance and security tests? It is worth doing them before migration (for comparative purposes).

Summary

These steps should allow us to plan the project, understand how many elements need to be changed. These elements are, of course, not only code, but also our internal processes, standards and habits. At this stage, it is worth making a rough estimate and building a project plan and considering how this project will harmonize with current activities (eg BAU). The latter issue is quite complicated and may require maintaining a few different workstreams simultaneously.