It's a big challenge for enterprises to plan and execute a Cloud Migration Strategy. There is a valid concern of getting stuck with a cloud provider and making switching to another provider difficult . for example, but if your current provider jacks up prices or if you do not like their services.
Infrastructure orchestration tools like Terraform can help. Terraform is an open source tool that serves as the orchestration layer for your application infrastructure in the cloud. As a bonus, you will also be able to version control your infrastructure, and it will make it easier for you to switch providers if you ever need to.
Other valid concerns in cloud migration are security, control, audit, separation of duties/roles, etc. Most companies are doing some POCs and a few teams are directly migrating their applications to the cloud and calling it an early success.
This model is not scalable.
Very soon, these teams will realize the pain of sharing VPCs and other resources with hundreds of other applications, not to mention the challenges of supporting multiple environments for each application.
On a side note, I really like Google's approach with GCP. It's much more streamlined, with each cloud instance divided into organizations and projects.
For an enterprise approach to cloud migration, you need to get "your head in the cloud."
Centralized API Control for Projects and Applications
Think of your cloud as a big API. You can control this API through a frontend web interface. For large enterprises, it will be important to manage it through a frontend application that they can control and manage. API strategy is going to play a key role in cloud migration.
Example : PRJ001, PRJ002 etc.
Defined Roles for Each Team/Project/Product/etc.
Think in terms of Roles. Essentially, roles can be defined as admin, write, or read access for each cloud resource. Define your Roles clearly for each team member and for every project/team/application/etc. Make the application owner/approver responsible for making sure that they approve each request with diligence.
Ownership Role : PRJ001_Pri_Approver, PRJ001_Sec_Approver
Developer Role : PRJ001_Dev
ReadOnly Role : PRJ001_Read_only
Internally accessible Public Projects/Frameworks
If all teams are using the same archetype/framework/etc., have an open access area for your architecture framework and common applications. It makes integration easier on the Product level. I am assuming here that an enterprise product consists of multiple applications.
Internally accessible Git Repo for Framework Projects.
Internally accessible hosted Repositery for Frameworks reuse. ( Nexus/Artifcatoy ).
Think of All Enterprise Offerings as a Service
Think of all the enterprise offerings, such as databases, security, compliance, audit, etc. as a service and try to extract each service from the cloud API frontend. Also, each cloud provider has some paid offerings to extract some of these reports directly. In cloud terms, that means considering your available managed and unmanaged services.
IMP: Come up with a Naming/Tagging statergy for each Cloud Resource.
AWS Cloud use taging for each Resource and for each environment ( eg: DEV , INT ,PRD )
PRJOO1_DEV_Ec2_01 - EC2 DEV instance No. 1
PRJ001_INT_DB2_03 -- Database Instance No. 3 for Integration Environmnet.
PRJ001_PRD_Vault -- Security /Vault Services for production instances .
As always , feel free to comment or reach out to me if you have any questions .
I can be reached at email@example.com.