Welcome to part one of this two-part series featuring the top 10 mistakes organizations make when migrating databases to DBaaS platforms. In addition to diving into these mistakes and how they happen, we’ll take a look at the impacts they may have on your environments. We’ll then provide recommendations based on our experience with cloud migrations so that you gain the insights you need to mitigate these common mistakes and have a successful cloud journey.
1. Underestimating cloud migration and ongoing costs
One of the biggest challenges shops will face with cloud conversions is that the costs often exceed initial budge estimations. DBaaS systems aren’t products; they are entirely new architectures. Like all new architectures, they will have a wide-ranging impact that affects all areas of IT and also how technology supports business operations.
DBaaS platforms will change how your organization designs, develops, accesses, administers, monitors and documents their database systems. The budget to convert a database to DBaaS cannot be finalized until a detailed evaluation of the database being migrated is performed. The analysis often identifies conversion issues that need to be overcome.
Some issues will be “easy fixes.” Others will be more challenging, and some will cause a significant impact on migration timelines and costs. Depending on the vendor and DBaaS product chosen, you may find that you will be tailoring your database configuration, tools/utilities, interfaces, SQL statements and procedural languages to work in that vendor’s environment. These customization activities take time, and in some cases, a lot of time. Funding for these migration activities needs to be included in the overall budget estimation. You will also need to factor in costs for training, documentation and organizational changes. We’ll learn more about budget implications throughout the course of this article.
During a CIO conference discussion RDX hosted, a CIO from a large organization that has a cloud-first strategy was asked how he budgeted for cloud migrations. His response was, “It’s simple – I just take whatever my team gives me and double or triple it.” Although it generated laughter from the audience, there were many head nods in agreement.
Cost overruns, unhappy management team, taking shortcuts to reduce costs, poor implementations
Perform a robust evaluation of the new architecture‘s impact on your organization. Allocate human capital, create project plans and allocate funding to the migration process and ongoing DBaaS support. Then be prepared for the surprises that can occur when you migrate to any new architecture.
Consider hiring consultants who have a well-documented background in cloud architectures to provide you with advice. Work with a cloud database services provider like RDX. Don’t go it alone as mistakes are costly, and cloud migrations have high visibility in all organizations.
View RDX’s Insights Series webinar recording titled Cloud’s Hidden Impact on IT Support Organizations. There are several webinar recordings on RDX’s YouTube Channel that provide hints, tips and migration demos to help you convert on-premises databases to several DBaaS platforms.
2. Underestimating the organizational and procedural changes required to support DBaaS environments
DBaaS systems may require changes to your support team’s organizational infrastructure. DB and application architects play important roles in the selection, configuration and implementation of public cloud-based DBMS platforms. Existing staff will have new responsibilities, and new positions may need to be created to support the new architecture.
Because the environment is different than on-premises systems, you will have to update your change management processes and support documentation. How long that takes and the number of techs you will have to dedicate to the project depend on the architecture you choose and how stringent your change management processes and documentation requirements are.
Larger shops traditionally have more documentation and procedures in place than smaller organizations. In addition, organizations that are governed by internal, industry-specific or governmental regulatory compliances are required to have more documentation and standardized administrative procedures.
Failed audits, not adhering to internal best practices and change management procedures, poor support, compliance issues, increased security vulnerabilities
Add organizational and procedural documentation evaluation steps to your cloud migration project plan. Consult with on-premises support, security and auditing teams to review current documentation and procedural requirements.
Here’s a starter set to jumpstart your evaluation: security, disaster recovery, change management, turnover approvals, monitoring, problem resolution, job scheduling, administrative best practices, repeatable processes, internal, industry specific, governmental regulatory compliance, naming conventions – [[add your additional required documentation here]]…
3. Not providing internal personnel with sufficient time and training to learn the new architecture
Your staff will need to be trained to learn the new DBaaS architecture. You will have to commit resources and then provide them with the time required to learn the new platform. Provisioning, administering, tuning, securing, monitoring, backup/recovery, disaster recovery. It’s the same basic principles of good database administration that apply to all DBMS environments, but your administrators will be using different tools, utilities and commands to perform those support operations.
Migration issues, poor ongoing support, continued problems after migration
Don’t expect your staff to become cloud experts overnight. There will be a learning curve that varies according to vendor and DBaaS product. Build test DBaaS systems and provide sufficient time to allow your support teams to learn the new platform. Encourage staff to take vendor- specific training courses and pursue certifications. Hire personnel who have experience supporting cloud systems to act as advisors and mentors to fellow personnel. Leverage consultants and third-party service providers, like RDX, to quickly acquire additional expertise.
4. Not fully understanding the vendor’s costing models
Evaluating initial and ongoing costs is critical. You aren’t going to be purchasing your environment; you’ll be renting it. Those rental fees will vary based on vendor, DBaaS product, system configuration and workloads.
You can search the web and find numerous cases of shops that didn’t do their due diligence, created DBaaS systems and were surprised at the charges they were incurring. Each vendor has different ways of charging the customer. Although the costing criteria will vary according to each cloud vendor, here are some of the more common factors that affect pricing: CPUs and CPU processing power, memory and disk sizes, amount of IO generated, network bandwidth and disk subsystem performance guarantees, storage for backups that exceed vendor allocations, HA configurations and data transfers.
Understanding the impact data transfers have on monthly costs is often overlooked by many organizations. Most vendors will charge you for data transfers to the cloud system from the internet, out of the cloud system to the internet and transfers between availability zones and regions.
Cost overruns, poor system performance
Take the time to fully understand the cloud vendor’s pricing models – they can be complex. Follow the advice in the RDX recommendations for problem #5 below.
5. Not sizing the cloud environment correctly
Measuring the on-premises database’s resource consumption is required to initially configure the cloud system’s performance tiers and estimate monthly rental fees. A big challenge for most shops is accurately measuring their on-premises DB system’s resource utilization. Technical personnel who are responsible for supporting the on-premises database will need to measure key resource consumption indicators including CPU, memory, disk storage, IO and data transfers into and out of the environment.
Performance and resource utilization monitoring becomes even more critical in the cloud. Your organization will be renting the DBaaS system, and the vendor will charge you based on resource consumption. Planning for database growth is an important component when forecasting future rental fees. Technical personnel will need to identify any changes (concurrent user increases, new application programs, new queries, data storage growth) that have the potential of increasing resource utilization. They will use this information to forecast the impact the change may have on current performance tiers and resource allocations.
We all know that it can only take a few improperly tuned queries added to the system to impact the resource utilization of any database environment – on-premises or the cloud. In addition to the traditional poor application performance and transaction time outs that can occur, sustained increases in resource utilization may result in your shop being forced to upgrade your performance tiers and configurations.
The process to select higher performance tiers and increase resource allocations is pretty straightforward in most cases. The key phrase in that last sentence is “most cases.” Vendors understand how important it is for customers to be able to scale their DBaaS resource allocations, but, depending on the vendor chosen, there may be an outage required to apply the change. Monthly costs will also increase.
Cost overruns, poor system performance
The first step to accurately size your DBaaS instance and estimate your rental fees is to fully understand what metrics the provider uses to calculate costs. Work with your on-premises support teams to measure your current resource utilization and estimate future workloads. Take your time during instance configuration and leverage vendor utilities that provide cost estimates.
Most cloud vendors provide a cost calculator that you can use to estimate your monthly charges before you provision your DBaaS Instance. Use the cost calculator to perform “what if” scenarios. Select different payment options, regions, instance classes, performance tiers, disk allocations and HA configurations. Read the calculator’s help information to better understand the calculations and costs.
After you migrate, one of your top priorities, in addition to making sure everything is working, is to monitor resource consumption. This includes setting up resource consumption, monitoring and billing alerts. If you don’t, you may end up with a budgetary surprise or two.
Thanks for reading. Check back soon for mistakes 6-10!