I have been asked a few times on how to migrate databases in the cloud. Sometimes I’m confused and have to pause before answering such question. Not because I don’t know how, but it’s more that I’m trying to figure out what is the motivation behind the question. In short: it should not be different than migrating databases on the on-premises servers. In other words, the only difference is that, the servers on the cloud are managed by a third-party provider.
Of course, there are certain aspects such as network and security that have to be extra taken care of before, but then it’s more for system administrators (the third-party provider of your choice has to be able to help you in this area). From a database administration’s point of view, everything else should be familiar, if not the same at all.
Having said that, these are the steps I would do if I were to migrate databases in the cloud.
0. Understand why you want to migrate
Before you even start migrating (therefore I call it step 0), you have to make sure that you understand why you want to migrate your databases in the cloud. It has to be more than just a following a hype or “because everyone else is doing it”. Think about how migrating databases could benefit your organization: financially? Reduce the number of on-premises servers and hence IT workload? Have a team scattered around the globe that needs access to the databases? Or just simply following orders from the CTO?
1. Know your goals, applications and stakeholders
Once you know why you want to migrate, you have to define and set goals for this. Is it for development and/or test environment only? Or for full-blown, enterprise-wide productive applications? It determines the effort and budget of the project.
You need to identify which applications could be affected by this migration and who the stakeholders are. Never not involving stakeholders. They need to be aware of what is happening all the time. Organize a weekly meeting, for example, is a nice gesture (probably more often at the beginning) for setting expectations.
2. Define the cloud model
The term public cloud, private cloud, and hybrid cloud should be familiar to you and you should define which one is suitable for your organization.
3. Data assessment
Are we talking about a hundred gigabytes or a few petabytes? How sensitive are the data? For a compliance reason, some data must stay on-premises. For data migration itself, a good third-party cloud provider can (must) help you with transferring the data from your location to theirs. They probably even already have a migration service in place.
4. Budget and cost calculation
No project has an unlimited budget, and every cost (CAPEX and OPEX) must be carefully calculated. At this stage, it is very important to work closely with your prospective third-party cloud provider. They should be able to tell you how much it would cost (some offers a fixed rate, the others depend on the I/O, requests, number of users, etc.).
5. Choose the provider
There are perhaps tens of thousands of third-party cloud providers around the globe; the biggest ones are obviously Azure, Amazon AWS, and Goggle Cloud Platform. Depending on the result from steps 1 to 4, you might want to consider also smaller, local players as oppose to these big enterprises.
The main benefit with a smaller provider is, they might assign a special account manager for taking care of all your questions and needs personally. They might even create a small team to help you migrating your data until it is up running. On the downside, their servers and resources might be limited.
Read carefully their service level agreement (SLA).
6. Plan: set up the migration dates, fallback and backup plans
Depending on how big the data are and how many users and applications are accessing them, you may have to set up several migration dates to avoid chaos by migrating everything on the same date.
I don’t think I need to say any further regarding fallback and backup plans. Developers and Project Managers are the most pessimistic type of job categories, in this case, for a very good reason. If you don’t expect the worst on the migration date, you don’t plan enough.
Leave a Reply
You must be logged in to post a comment.