Recent news around the doubling of cost to run Oracle databases in the cloud has many enterprises searching for alternatives. The underlying database for many applications is a critical component that has had years of performance tuning, modeling and other optimizations to ensure rapid application response time. With this long-term investment, many organizations are hesitant to change the underlying database for in-house built and 3rd party applications. While there is never zero risk involved in IT changes, database migrations can be done safely and successfully while ensuring data integrity, application availability and performance are maintained at peak levels for user satisfaction.
When embarking on a database migration to eliminate Oracle, pre-planning is critical to ensure organizational alignment on goals, technology choices and migration methods. Achieving this alignment early in the process will ensure uniformity in migrations and proper planning and testing for low-risk migrations. Figure 1 shows the high-level steps necessary to organize, decide, plan and execute a database migration with the intention of changing database platforms while migrating applications to a public cloud platform.
Identify the Reasons for Migration
When beginning a database migration project, it is important to identify the key reasons to the organization for migration and their prioritization. This will help the organization speak a common language in later phases about how to select a target cloud platform, target database and the necessary tools to facilitate migration. The most common reasons organizations turn to migrating to alternative databases are:
- Cost Savings – As with any IT organization, cost savings are critical as budgets continue to get squeezed. Large spending on licenses and support contracts is often a target for evaluation. The elimination of Oracle has yielded multi-million-dollar savings for large organizations, even after the cost of migration is factored in.
- Avoiding Vendor Lock In – Many new applications today are deployed using tools and design methods to make the database and other components easier to replace, should a vendor change course or a new vendor jump into the market.
- Adoption of a Cloud-first mindset – As organizations look to eliminate highly capital-intensive IT assets, a cloud-first mindset is being used to drive workload to more cost efficient and flexible platforms.
- Agility for Application Teams – Application teams continue to ask for more flexibility to rapidly deploy non-prod environments and updates to production environments, without long lead times.
Inevitably there will be objections across the organization for these types of complex, high touch changes to the IT infrastructure. The focus should be on ensuring the organization has functional parity for the business users post migration, and avoid trying to map feature to feature from the source to target environments.
Identify Target Applications
When identifying target applications to migrate to new database platforms, the key is to evaluate the rewards of the migration, against your previously identify goals and the risk to business operations associated with the migration. Figure 2 outlines the common design patterns and the risk associated with each category of application if you are to migrate from Oracle to alternative databases.
The other element of identifying target applications for migration is to identify design patterns and features that are being used that will be more complex to migrate and possibly require remediation during the migration process. These can span a wide range of elements in complex environments, the most common ones that should be accounted for are:
- Business Logic in the Database – It is common in many organizations to keep business logic in the database layer, as triggers and stored procedures. To facilitate lower risk migrations and improved longer term application architectures, this logic should be moved to the application tier.
- Database Replication – The cloud provides a variety of new methods for ensuring data integrity and service availability that differ architecturally from on-premise methods of protection. Cloud migrations will require organizations to look at the methods used for data protection and modify both process and tools to ensure the proper level of availability in the cloud-deployed application.
- Performance Optimization Tools – Many organizations rely on third party tools to provide visibility into database performance and enable DBAs to tune queries for optimal performance. When moving to alternative databases, these tools should be validated against the new targets or replaced to ensure DBA visibility is not impacted on new platforms.
- Legacy Versions – Many enterprises still run older versions of Oracle to support specific needs, these will often require upgrades prior to migration to alternative platforms to ensure data can be properly exported or replicated to facilitate loading the new environment.
Identify Cloud Platform & Database
Next, you must decide on your target cloud platform and associated database. While many common databases like EnterpriseDB, SQL Server, MySQL and other will run on all public cloud vendors, each public cloud vendor has built their own specific capabilities that can lower operations costs and the time necessary for migration. Some examples of platform specific innovation include:
- AWS Aurora is an AWS-enhanced version of MySQL that provides many operational advantages around deployment, scaling and availability not available if a base installation of MySQL is leveraged.
- Azure SQL is a PaaS implementation of SQL Server, with many operational benefits to lower TCO compared to traditional SQL Server installations.
- EnterpriseDB can be run on any of the three major public cloud providers and provides the ability to run unmodified PL/SQL, facilitating faster migrations without the need for as much refactoring.
The evaluation of cloud vendors and target database platforms should be done in parallel so that tradeoffs and capabilities can be considered when making platform and database choices. The ultimate decision for targets has both financial and technical considerations. Often the public cloud vendors will provide access to subsidized tools to facilitate adoption as well as credits to support the initial build out of workloads on their cloud.
Identify Data Migration Method
After a target cloud platform and database has been selected, the method for migration of data must be chosen. The most critical question to this selection is, “how much downtime can I tolerate when I cutover?” This is a place where both the cloud vendors as well as third parties provide solutions that can be leveraged, depending on availability needs.
- Low Tolerance for Downtime – Tools from companies like Attunity can facilitate the replication of data while keeping multiple databases in sync, enabling rapid application cutover where downtime needs to be kept to a minimum.
- Moderate Tolerance for Downtime – Where a little more tolerance is available, the cloud platform vendors provide their own tools to facilitate both schema conversion, as well as data migration. AWS offers the Database Migration Service, and Microsoft the Assessment and Planning Toolkit and SQL Server Migration Assistant.
- High Tolerance for Downtime – AWS provides Snowball for environments where high latency is acceptable to facilitate the movement of large amounts of data that would overwhelm an enterprise’s upstream bandwidth.
With the high levels of availability required on many business systems, it is not a simple cutover. Particularly in complex environments where databases are receiving feeds from many sources and providing exports to others, testing is critical to ensure success. Executing a dry run prior to the formal migration will allow staff to validate checklists, validate skills and most importantly, test roll back procedures in the event the migration fails. These dry-runs enable the team to get comfortable working together in the various aspects of application, infrastructure, security and database operations that must execute in unison for the production cut over.
The dry-run is not a one-time event. It should be executed at a minimum, once per application and database being migrated, but could reasonably be done several times to ensure proper process and roll back procedures.
The final cut over of the database can be the highest stress period for the entire time. This should be done at a time that limits business impact, and provides a large enough window to properly test the new environment before business users being using the system.
Support systems should be put in place to take calls from developers, DBAs and business users who may identify mis-configurations or need assistance operating the new platform.
Database migrations are complex. It is rarely a simple case of one application to one database. More often it is a complex, interconnected ecosystem where ETL pipelines must be maintained, database exports must be rewritten and applications refactored to account for a new database with unique capabilities and features. Leaving Oracle is not a trivial task, but can provide an organization large benefits, both financial and operational. The ability to move between database platforms removes risk of vendor lock-in so that organizations can focus on application enhancements and investment of IT resources that will drive the biggest gains.