Your 10-step cloud database migration checklist

Why do a cloud database migration?

Before we begin, let us consider the scenarios in which cloud database migration would be a viable option:

• The ability to manage databases in-house is inadequate
• IT is not a central functional unit
• You’re an SME and need to cut initial capex costs
• You are working with new applications or developing one, and want to try the cloud as a testing environment
• Moving to the cloud for your disaster recovery (DR) backup, and using it as a trial run to identify issues and hurdles to database migration

The key advantages to cloud database migration are availability, scalability, reliability, and cost. The cloud infrastructure is scalable, and no capex investment is needed. Business are generally very open to database migration if security concerns are addressed satisfactorily.

Although database migration in isolation (without migrating applications) is not impossible to accomplish, it may not be very feasible. When your application resides in-house and your database runs on an external server, life will not be easy. The two networks need to collaborate seamlessly to provide fast and optimum functioning. The process must work in most instances, otherwise it will not perform any better than it did in-house. That is also why it is recommended to migrate the entire set-up onto the cloud.

Pointers for a successful database migration

1. Assess database size: Database sizing will determine what hardware is required, and how much storage and what instance will be needed after migration. This can be undertaken by the internal IT team itself.
2. Test applications before data migration: The applications the service provider uses to connect to the database have to be fine-tuned to the applications that will use the database. Applications running on the cloud database should also be compatible with cloud infrastructure, and provide better performance than the in-house set-up. The cloud datacenters may not be in the vicinity, and there may be high latency issues. Applications should be able to perform in such situations. Raise the issue with your service provider, and make sure you're both on the same page..
3. Data confidentiality is a deal maker: To begin with, you might want to migrate only those databases and applications which are not mission critical. First migrate those databases which can be hosted in environments that may not be trusted.
4. Design the service level agreement (SLA) document carefully: There are applications which will require 99.99% up-time. Make sure scheduled down-times don't interfere with your business needs.
5. Ensure scalability: The main attraction of a database migration to the cloud is immediate scalability. Services and infrastructure should ideally be scalable on the fly. Yes, that will have to be negotiated with the provider. Keep the service vendor in the loop about your business growth plans.
6. Mind your OS: Finding the operating system (OS) that works well with your databases is crucial. For example, Oracle is available for Linux as well as Windows. Although both serve the same purpose, there will be a huge difference performance-wise. Check for the same version of the OS on the cloud.
7. Eliminating garbage will reduce costs: Cleansing of data becomes very important as costing depends on the size of the data. As database size grows, costs will also go up. Make sure to eliminate garbage data from the database before migrating it.

Ways to overcome hassles

During your cloud database migration you may have to deal with performance and security issues. Here is how this can be tackled with ease.

1. Security: Your public cloud host could potentially be untrusted. It can reside anywhere, and there is no control of the customer over this aspect. One way out is to implement a private cloud. Factor this into your SLA. The provider’s job is to provide the infrastructure, make the data available, and adhere to the security policies of the agreement. The data massaging or cleansing activity must be undertaken in-house because in principle, the provider should not view or process any data from your database.
2. Applications performance may vary on the cloud: Keep in kind that data will travel over a remote network and not just a LAN after the database migration. There may arise a need for re-writing codes. Some applications will already be cloud-compatible, while others may not work at all. For example, Oracle has partnered with Amazon, but Oracle does allow for other service providers to host its databases. Know where your provider stands on knowledge of the various applications and databases that are in migration.
3. Multiple database migrations: Moving multiple databases can be a challenge if any applications depend on all of them. In such a scenario, the entire structure will have to be migrated to the cloud. The difficulty lies in finding a vendor who will host the multiple database set-up. In general, the migration of one or two databases to the cloud is more feasible than migrating many.

About the authors:

Devendra Murkute is the co-founder of Osource India. Deven has over 20 years of experience in the IT services industry across functions such as business management, practice incubation, service delivery, relationship management, and business development for domestic and overseas businesses. His domain expertise covers application conceptualizing, designing, project management, and software delivery.

Suraj Dubey is the vice president at Osource India where he oversees the planning and continual alignment of IT systems with strategic business drivers. He is responsible for the execution, implementation, and delivery of service / software solutions for Osource's customers. Prior to joining Osource, Suraj worked with the Indian Air Force as a Combat Member for over a decade, wherein he was involved in information security and software project development. He is post graduate in Software Engineering and holds ISO 27001 LA and CISA certifications.

(As told to Sharon D'souza)