Planning and design
Migration to AEM as a Cloud is a big undertaking and you have to think about it as a full-fledged and rather complicated project. It is worth starting (according to Adobe's recommendations) with a good diagnosis of the current situation, estimation to finally build a project plan. As the issues in this area are very extensive, I have prepared a few questions and tips that might help you go through stage 1.
1. What are our sites? What integrations, with what systems?
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?
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.