Ultimately a data migration to the cloud is a technical exercise – we will use technical tools to move data to a cloud-based destination. That said, there are two keys to a successful data migration project that are non-technical, but critical to success: database optimization and knowledge of the organizational structure of the company engaging in the migration.
I spent years as a consultant guiding customers through successful and unsuccessful Azure migrations. Migration tooling has evolved and improved through the years but, to be honest, tooling was largely never the reason a project wasn’t successful.
Cloud migration projects fail, in my experience, for one of two reasons: bloated databases force you into choosing expensive migration targets and/or organizational support for the migration project itself is lacking or nonexistent.
Managing Bloated Databases
Let us tackle bloated databases first. Obviously, this is a topic that could be deserving of its own series of blog posts, its own full day conference session, or any other delivery method for in-depth content. Since we just have a few hundred words here, we will hit the highlights:
Analysis and Optimization
It sounds glib, but the best way to save money in the cloud is to have your chosen cloud data platform store less and do less. In my experience, the technical component of a migration project that is most often missed is analysis and optimization of your current databases before migrating them.
That optimization should really take place on two concurrent paths: archiving data that is no longer needed as well as analyzing the current performance to see if there are optimization opportunities in the current data-related code and structures.
In many of your data migration targets in the cloud both the storage and compute are billed (sometimes independently). In other words, having too much data or working too hard to access and manipulate that data can cost you real money.
Performance Tuning
Finding data to archive (and archiving it) is one pathway to saving some money in that scenario. The other pathway to cloud savings is undertaking a performance tuning project before the migration project kicks off in earnest.
That would obviously take quite an investment in personnel but do keep in mind that there are tools to help you analyze and improve performance. The company who owns the very website on which you’re reading this makes some of those tools and they’re worth a look!
Encouraging Organizational Support
Now that we’ve talked about a couple ways database bloat can hurt us heading into a migration, let us turn our attention to how organizational bloat, disinterest, or downright obstinance can derail a cloud migration project. We will focus on two organizational objectives you’ll want to meet to keep your migration project on track: management buy-in and team member buy-in.
Management Buy-in
It may seem obvious that having management support for a large project like a cloud migration is essential. What is likely less obvious is that it may not be buy-in of the data team’s management that you should be worried about.
Remember that cloud migrations (especially the first one a company does) are likely going to involve the data team, the operations team, the networking folks, the security people, etc.
Those teams all have managers and executives above them and, perhaps, priorities that compete with the migration project. I’ve seen this firsthand, and it can stop a migration project dead in its tracks.
Taking the discussion of management buy-in a step further, remember that you may need to get the buy-in of managers and executives who, per the org chart, do not necessarily seem like they should be involved.
These people are generally the ones who cut through red tape, who have built relationships across the organization, and who you will want in your corner in order to execute the migration successfully and on-time. It is worth an investment of your time to find out who these people are and to build a relationship with them.
Team Member Buy-in
Finally, let’s talk about team member buy-in. We need to ensure that the people tasked with doing the work are invested in the project and its success. While I’ve mentioned that many teams other than the data team are often involved in migrations, we will focus on the data team.
In fact, we will focus on one simple thing: change is hard. You are likely to have people on your team who don’t want to move to the cloud because “it’s different”, “it’s difficult”, or a variety of other reasons. Make sure that you devote time to assuaging their fears and giving them access to proper training to understand the world they are headed into.
There is excellent paid training on platforms like Pluralsight and excellent free training resources from Microsoft but there are also community outlets like virtual user groups, SQL Saturdays, Data Saturdays, etc. that will equip them with the skills and knowledge they will need.
Migrations are complicated projects, but they can be successfully executed. Just remember how critical it is to get the optimization and organizational components completed as you continue your journey to the cloud.
By Matt Gordon
Matt Gordon is a Microsoft Data Platform MVP and has worked with SQL Server since 2000. He is the leader of the Lexington, KY PASS local group, a frequent community speaker, and an international conference speaker as well. He has supported several critical systems utilizing SQL Server and managed dozens of 24/7/365 SQL Server implementations. He currently utilizes that real world experience as a data platform architect helping clients design solutions that meet their ever-changing business needs.
