In the last few months, I've been traveling around at a few of the Redgate Summits (one more in NYC coming) running panels on cloud journeys. I've had industry experts, both technical and managerial, discussing their approaches and journeys with advice and caveats for others. It can often be more than just migrating systems, so a lot of people have started to talk about cloud transformation.

However, in some cases, this is just a migration. A lot of companies just lift-and-shift their databases into the cloud, along with various other services. While this is a quick way to get into the cloud, it isn't much of a transformation. If you review and right-size the resources you've provisioned, maybe there is a bit of a transformation, but not a lot.

Instead, the idea recommended by most vendors and consultants is to transform your software to work in the cloud. This might be moving to containers, to using more cloud-native services, or re-architecting your software to embrace to way cloud vendors provide services. Often this is a major project, though it can provide advantages over time with cost savings, more efficient code, and better-trained developers.

That last one is key, as a lot of the advantages of the cloud require your developers to write better code and re-think how they interact with data services. Code costs money, and poor code costs more money. This is also true on-premises, but it's more true (and more visible) in the cloud.

I was surprised at how many companies had embraced the cloud and how many had seen savings. I met quite a few companies that had moved their databases (including large enterprises) 100% into the cloud. They've seen savings, but they also rigorously audit resources and the provisioned sizes.

The cloud isn't for every organization, and not for all workloads. There are more than a few companies that have struggled to achieve the results they want in the cloud, be these performance or cost measures. I suspect some organizations will never move fully to the cloud, and may never move databases. However, it is a tool that we technical people ought to understand and learn why we recommend for or against a move.