I get a pitch a day from [enter any PR firm here]. The details vary, but the core idea is the same: "We have defined the steps to migrate to the cloud, so follow us."
To be honest with you, I often bite. If nothing else, I'll take a look at the press release, white paper, or website. Often there is a list of pretty obvious things to do, such as "define the business objectives" and "define security," but the details are nowhere to be found. Why? Because the details are hard and complex, and the vendors would rather that their steps seem more approachable by the IT rank-and-file than ensure they will actually work.
Moving applications, systems, and even entire architectures to cloud-based platforms is no easy feat. In many cases it requires a core understanding of data, processes, APIs, services, and other aspects about the existing state of IT before planning the move. Yes, the details.
For those in IT who are charged with migrating to the cloud, this is often where they drop the ball. They jump right into standing up cloud instances and try to make the move without a full understanding of the project. Failed cloud project after failed cloud project can be attributed to this error being made by people who followed stepwise processes outlined by a cloud provider, technology vendor, or big consulting organization.
By the way, although it's more complex than most people understand, migrating to the cloud is not at all difficult. You need to understand this process for what it is: An architectural problem that requires both the as-is and to-be states to be defined so all issues are understood, including metadata, performance, security, compliance, and governance.
Understanding your problem domain leads to the right process for migration. If you know what you want to move and why you want to move it, you know how to test for security and compliance, and you understand how to create an effective migration plan that sweats the details rather than ignores them.
