Welcome to the second part of this two-part series in which we discuss the top 10 mistakes organizations make when migrating databases to DBaaS platforms. In part two, we discuss mistakes 6-10.



6. Not accounting for cloud/on premises DBaaS feature mismatch



The impact of cloud/on-premises feature mismatch is minimal for infrastructure-as-a-service, which we know is just a server in the cloud.  However, there are significant differences between on-premises DB features and their DBaaS counterparts.



Let’s use Microsoft SQL Server as an example.  If we compare the feature differences between Microsoft’s on-premises version to Amazon’s SQL Server RDS cloud offering we’ll find that there are numerous differences between the two products. If you currently use SQL Server on-premises, you’ll need to be aware of these differences before you begin migrating existing databases or creating new instances on Amazon RDS. 



This feature mismatch isn’t just an Amazon issue. Take a look at Microsoft’s Azure SQL DB documentation.  It provides a list of differences between SQL Server on-premises and its DBaaS counterpart, Azure SQL DB.  They are two database products offered by the same vendor.



Some of these feature mismatches are complex, and it can be a challenge to leverage the like functionality provided by the cloud vendor. DBAs and developers are often required to work together to come up with a viable solution.



IMPACT:

Failed migrations, application and third-party product failures, cost overruns, post implementation emergencies



RDX RECOMMENDATIONS

Your shop will need to identify all of the feature differences between your chosen DBaaS architecture and your on-premises databases. DBaaS vendors’ product documentation will provide an on-premises to cloud feature comparison. Usually, the list will contain the on-premises product’s major features, followed by information that describes the feature as fully, partially or not supported.  DBaaS vendors understand it is in their best interest to help customers easily perform DBaaS migrations. The feature comparison often contains recommendations and workarounds for partially or non-supported features. You’ll see the vendors use the term “like functionality.”  You’ll need to carefully evaluate how much effort will be involved to retool the application and/or database to leverage the vendor’s “like functionality.”  



In addition to providing a feature comparison in Azure SQL DB’s documentation, Microsoft also provides the Data Migration Assistant (DMA).  DMA scans your on-premises database to identify compatibility issues that will impact the migration or the ongoing functionality of the cloud Azure SQL Database. The utility also generates a set of alternatives and workarounds available in Azure SQL DB.



You will need to identify the features that are partially or not supported and the vendor’s like functionality. Then, you’ll need to distribute them to your third-party application vendors and internal developers to determine if their applications will continue to work with a DBaaS system. If they rely heavily upon a particular feature to provide critical application functionality that is not provided by the DBaaS system, you will need to modify the application to leverage the vendor’s like functionality or create your own custom workaround.



I’m not stating that DBaaS environments aren’t as effective as on-premises; they have different features, and we all need to be aware of those differences.



7. Not verifying that your preferred toolsets and utilities will continue to work with a DBaaS system



Many of the third-party tools that include monitoring, security, application development, business intelligence and auditing can be challenging to integrate into a DBaaS architecture because of the modifications the vendors make to their systems.



We just discussed the potential impact of on-premises to cloud DB feature mismatch. We also need to consider the impact that a different architecture has on your toolsets. Will your in-house tools and utilities be able to connect and interact with the cloud environment?  



A quick example to reinforce this point would be your favorite in-house monitoring product. Although the cloud vendors do provide robust monitoring capabilities, you may want to continue to use your existing in-house product to monitor DBaaS environments. You will need to determine how your in-house monitoring product will connect to the cloud target and access the availability, resource utilization and performance statistics. Because the metrics and evaluation criteria used to analyze performance and availability often differ between the cloud and on-premises DB platforms, you will need to create new monitoring evaluation criteria. 



Your shop’s favorite in-house and third-party tools may need to be modified to access the DBaaS platform. In some cases, finding a replacement product that inherently works with the cloud system may be more financially attractive than the costs associated with modifying an existing tool.



IMPACT:

Loss of functionality and visibility into the cloud system, product failures, cost overruns, post implementation emergencies



RDX RECOMMENDATION:

You will need to identify all of the build, administration, monitoring and access tools that your organization uses to interact with your on-premises databases. All shops usually have a couple of must-have products that are frequently used. Contact the homegrown product’s internal owners and third-party vendors to discuss the impact the new architecture will have on their programs. 



The popularity of the cloud is driving most software vendors to make sure their offerings work with cloud systems, but you will need to double check. Our recommendation is to create a list of your must-have products and verify that those tools and utilities will continue to work with the DBaaS database. 



8. Not identifying the database’s interaction with other systems



A common mistake is not identifying how the database interacts with other applications.   How much data do you need to transfer back and forth to the cloud DBaaS system? How much data and how long does it take to send or receive it? Can your network and cloud connection handle the increased volume? In addition, we’ll need to determine how the cloud provider charges us for those inbound and outbound transfers. 



What we need to remember is that no database is an island. They take feeds from flat files and other database applications and produce output that is ingested by other systems and end users. Getting a lot of data into and out of a cloud architecture can be challenging especially if there are tight time constraints and large data volumes that need to be transferred. How is the database populated? Is it loaded using flat files or database to database data transfers? Are their deadlines for those processes to be completed by?



A popular feature in any DBMS is using its inherent linking capability to access data in other systems. You can use a single SQL statement to access one database and then use links to join that information to data residing in other DB systems. Will those other databases be on-premises or will they also be in the cloud?   



Does the DB generate a lot of output? Do you use that database data to refresh other systems? Does it generate large reports or flat files and other data streams that are used as input to other applications? How will you transfer data back and forth to the cloud during daily database operations? 



IMPACT:

Missed data transfer deadlines, data not current, poor performance



RDX RECOMMENDATION:

Perform an extensive evaluation of the data transfers into and out of the DBaaS platform.   Identify all of the interactions the database being migrated has with other systems. Thoroughly test the performance of data transfers and DB-to-DB communications.



9. Inadequate testing and migration plans



The cloud isn’t a new server, DB product or an operating system; it is a new architecture. As we learned throughout the course of this discussion, there are many topics that require comprehensive evaluations throughout the entire DBaaS migration life cycle. Like any new architecture migration, your conversion checklist will need to be well thought out and detailed.This is not an architecture that should be entered into without extensive analysis and forethought.   



IMPACT:

Failed migrations, poorly performing systems, post implementation surprises, ongoing issues



RDX RECOMMENDATION:

Planning for a cloud migration is like any other complex technical project. A multi-disciplinary team should be created that includes representatives from database, network, OS, security, application support and business units. The team will create the traditional project goals, strategies, migration activities and timelines. Like all system migrations, that process will include the creation of robust test plans that thoroughly evaluate application functionality, backend support processes and system performance.  



Unlike traditional, on-premises projects that migrate a database from one platform to another, transitioning to a cloud DBaaS system will also include testing on-premises to cloud data transfers, interactions between cloud to cloud  and cloud to on-premises systems, application functionality affected by cloud/on-premises feature mismatch, third-party tools, utilities and applications that access the database.



In addition, a separate migration checklist document will need to be created that includes the mechanisms you’ve chosen to initially create your cloud database environment. The document will include the utilities you use to initially seed and synchronize the DBaaS platform with the on-premises system and the detailed steps your migration team will execute to perform the final migration and verify that the process has completed successfully.



10. Losing visibility into the DBaaS systems after the production cutover.



A common concern for many shops that use DBaaS is the lack of visibility when you compare DBaaS to IaaS and on-premises systems. Clients that are required to adhere to internal, industry-specific or governmental regulatory compliances are unable to provide the often enormous volume of supporting evidence their auditors need to verify the environment meets the frameworks’ control objectives.



Monitoring tools and individual metrics provided by the cloud vendors vary greatly. Migrating to a cloud system increases the need to accurately monitor and measure system availability and performance. Once again, you will be renting the environment, and you will be charged based on the resources your new DBaaS system consumes. Each cloud environment requires a unique monitoring implementation to ensure that critical cloud applications are highly available and high performance.



Because DBaaS is a new architecture, administrative teams are unable to apply their on-premises best practices to improve system visibility, performance, availability, security and overall quality. Their lack of experience also prohibits them from fully leveraging the DBaaS product’s features that provide the information they need to better understand daily DBaaS database operations.



IMPACT:

Failed audits, poor system quality and performance, lack of ongoing improvements, not fully leveraging DBaaS features, recurring problems  



RDX RECOMMENDATION:

Thoroughly evaluate the vendor's monitoring and auditing instrumentation to design and implement a monitoring strategy that meets your shop’s needs. Meet with auditing teams to agree upon the evidence they need to demonstrate compliance with all regulatory frameworks.



Many cloud vendors provide advisors that scan your environments, apply a set of best practices and generate recommendations. RDX recommends that you leverage the advisors throughout the cloud deployment, development and mature system life cycle.



Wrap-up



The benefits DBaaS environments provide far exceed the migration and support challenges highlighted in this article. The dramatic growth of DBaaS implementations shows that hundreds of organizations have made successful cloud transitions.  



The goal of this series was to make your first migrations to DBaaS as painless as possible.  When you identify and address issues early in the cloud migration life cycle, their impact will be minimized, and you'll have fewer surprises when you flip the switch on your new DBaaS system.



If you need assistance, RDX is always here to help you in your cloud journey.