Today more and more companies are adopting big-data and cloud-based architectures to meet growing business demands. However, while these new technologies offer a number of operational benefits, there are some key problems which must not be overlooked.

Benefits of migration

The key benefits of migrating databases to the cloud are similar to those associated with moving any workload to the public cloud; agility, accessibility, scalability and cost-effectiveness.

“That said, there are also more specific benefits relating to databases that can be achieved,” says Mark Shaw, manager of Systems Engineering Western Europe at Rubrik. “When organisations migrate databases to the cloud, they can take full advantage of the additional services which exist in public cloud that may not be available on-premise. Cloud also offers an elastic scalability- which is useful when demand is high for a particular database.”

Eric Schrock, CTO at Delphix, says that organisations may want to re-platform to a new architecture to support evolving business needs.

“This could include moving to a managed database service such as Amazon RDS, adopting open source technology such as PostgreSQL, or moving to a horizontally scalable data store like Cassandra,” says Schrock. “This can lower costs while increasing velocity through modern tooling. This is a significant investment reserved for critical initiatives; but the first step is often getting the application, and hence its data, to the cloud in its current form.”

When should a database be moved

The scenarios that could merit migrating a database to a cloud service are generally driven by business requirements. For example, when an on-premises application service is being re-architected as part of a digital transformation strategy.

Other examples may include “seasonal businesses which scale on-premises for peak and wish to challenge the status quo”, says Martin Jones, professional services director at SCC. In that case, companies are able to “use cloud database services in line with performance requirements, or when a business wishes to use a wider suite of tools, to gain insight into their application, which could be prohibitive if carried out on-premises,” adds Jones.

Can a database be moved to the cloud in isolation?

Unlike a collaboration system, which is a natural candidate to move in isolation to other IT systems, a database is by its very design connected to a variety of other systems and services making up a multi-tiered architecture.

This architecture can then be queried and updated by users belonging to different groups, such as employees, partners, and customers, and also mined by analysts and researchers seeking future trends.

“It is vitally important to remember, in order for the database to be migrated successfully, that all the associated tiers and systems are known, their function clearly understood, and their performance benchmarked,” says Paul Griffiths, senior director of Advanced Technology Group at Riverbed.

“Only with a complete view of all the components and their interactions with each other, can it be decided which elements need to be migrated along with the database itself.”

Moving a database

Migrating a database to the cloud can seem like a daunting task, and in some cases, it’s the initial challenge of figuring out what all the “moving parts” are which can cause migration projects to fall at the first hurdle.

“This can lead to organisations never being able to fully exploit the benefits of cloud. While that may not bring about the demise of a company, it could affect how competitive they are able to be in the market,” says Griffiths.

Schrock says that the first challenge is realising that database migration is not a one-time event. Moving your database to the cloud is only relevant if you migrate the application, too, which is cumbersome and can take days to weeks to months. During this time, teams must ensure that their applications will run in the cloud, that they can develop effectively within the cloud, and minimise disruption during the final transition.

“All of this requires high-quality data in the cloud for continuous testing across the application, cutover process, and SDLC integration,” says Schrock. “Failure to drive quality testing will at best slow down the project, and at worst cause significant disruption, poor quality post-transition, and an inability to move quickly to address problems.”

Shaw says that security concerns are often another huge barrier when it comes to migrating databases to the cloud.

“Data has become the most valuable and important asset for all organisations and, therefore, effective protection is paramount for the success and future growth of the business as a whole,” says Shaw. “If your business’s data protection is not adequate and you suffer a breach then your reputation, brand and, by extension, the entire business is at risk. Hence the reluctance of some businesses to adopt new strategies and embrace cloud.”

Move it, then monitor it

When a database has been migrated, it’s important to use tools like SQL Server Query Store to monitor, evaluate and understand the baseline data – for example, transactional throughput and surges of daily/weekly/monthly activity.

“These metrics will help organisations to determine whether to move from standalone PaaS databases to PaaS Elastic database pools. Lastly, it makes good business sense to use the data to show the TCO reduction to key stakeholders such as the CTO,” says Alan McAlpine, senior consultant of Enterprise Data at IT services firm ECS.

Leaving databases on-premise

Not all databases should go to the cloud, explains Roberto Mircoli, EMEA CTO of Virtustream. “Once you have identified a specialised enterprise-class cloud provider which guarantees the level of security, compliance, performance and availability required by your business, then what should be left on-premise is really only what’s constrained by residual latency limitations or extremely stringent regulatory requirements.”

“So for example, some particular applications in the automotive industry leverage manufacturing integration and intelligence to collect data in real-time from the automation systems to plan the procurement of components and materials; in these particular cases, 20, 15 or even 10ms of latency are not acceptable,” he says.

Image: Shutterstock