I have been speaking to people about database migrations to the cloud a lot over the last few weeks. One thing that has jumped out at me is that we seem to focus on the process of moving data being the migration rather than one step in a larger process. Many people neglect the discovery and analysis phase up front which is vital to making a database migration a success. I suspect that this is borne out of our mindset that we just backup and restore from one system to another that looks largely the same so no need to do deep analysis.

While the cloud is just another place to run a database, the reality is that it brings new challenges outside of just making sure the database is running. This means we need to look at the bigger picture of how the database fits into a wider system.

Often, we have external factors such as datacenter lease renewals, hardware refreshes, or license renewals which drive the need to do this work. In many cases this can mean short timelines to move a lot of systems and “just get it done” which means compromises need to be made.

This really got me thinking that much of what we do in the discovery phase is built on what we should be doing as DBAs every day, but which can be pushed because of other pressures. How many of us can, hand on heart, say we have full performance baselines for our database servers, know which applications connect, and what processes interact with the database. We may have that in our heads but very rarely documented.

So, my challenge to you (and myself) is this, think about what is important for your colleague to know to pick up and move a database at short notice, and then see if you have all that information to hand. If not, think about how you can gather it and put a process in place that automatically keeps track of that.

In my experience, that colleague, is often future me and I really wish past me had gotten round to documenting what I needed when I had the time.