Deploying open-source database management systems (DBMSs) can deliver unique benefits to enterprises, including lower costs, greater flexibility, and innovation not always available with proprietary database solutions. However, migrating from an existing proprietary product to an open-source alternative requires planning and attention to ensure the process doesn’t go awry.
The appeal of open-source licenses starts with the cost—free—and access to the source code, with the ability to modify and distribute that code royalty-free for its own purposes.
Then there are countless extensions and add-ons that can improve database performance markedly, many of which are also free. With proprietary products such as Oracle Database, similar features quickly add up.
Database migration from existing proprietary systems to open-source alternatives can be complex, so you need to go into the project with your eyes open.
“Open-source database migration typically involves more than just a database,” Jeff McCormick explains in a TechTarget guide. “It is more accurately described as a database ecosystem transition, which can include multiple independent projects for management, monitoring, tuning, connection pooling, high availability and third-party support.”
First step: Assess migration needs and capabilities
A crucial first step in database migration to open source is a frank assessment of your existing team’s abilities to complete the project successfully. In general, database administration skills are not readily transferable among different platforms. Recruiting open-source DBMS talent can be costly and frustrating because you’ll likely compete for talent with many other companies.
Checklist: 9 database migration best practices
Assuming you already have—or can put—the right skills in place, here are nine best practices to keep in mind:
- Begin with a thorough analysis of technology-related issues and evaluate the compatibility of client, application server, data access, and database features.
- Determine the assessment scripts and tools available to you and whether your team has the skills to put them to good use.
- Ensure any relevant commercial software application you are using is certified for the open-source solution. If not, determine your alternatives.
- Migration presents a good opportunity to clean up your architecture and database content. Deprecate objects you no longer need. If you store large files, evaluate whether you can separate them into a lower-cost storage option to reduce database size and resources needed for backup and restores.
- Do not waste time replicating data that you don’t need, for example, backup data and temporary tables from past maintenance.
- Determine incompatibilities between the old and new databases and estimate the time and cost required for migration.
- Decide which applications will need to be refactored.
- Determine whether the open-source DBMS can support the customizations and dependencies of the existing DBMS, and if not, what your options are.
- Allow ample time for performance testing before rolling out the new DBMS, or you’re sure to have unhappy users blaming you for making them switch to a new tool.
Cloud issues
Many organizations turn to open-source DBMS options to facilitate their migration to cloud. Make sure your motivations are solid and you fully understand the cost ramifications.
“Most enterprises just want their move to the cloud to be fast and cheap. That means they take a lift-and-shift approach to data migration,” writes InfoWorld columnist David Linthicum. “At first, this method may make budgetary sense. However, taking the long view, lift and shift means you’ll have to migrate your data twice: once, the wrong way, and second, the right way.”
The cost of cloud resource consumption can also be quite high. Make sure you understand how your costs will increase if usage scales rapidly.
Also, make sure you know what it takes to move back on premises or to another cloud vendor. Some cloud vendors are producing their own customized versions of open-source databases that may effectively lock you in.
Support at scale
Unlike a vendor-supported proprietary DBMS, the traditional open-source support model was largely based on self-support, trial and error operational models, and support from communities of contributors. That may not be sufficient to meet mission-critical operational requirements when trying to pinpoint a performance issue or tweak a needed feature.
“You can’t fully rely on an open-source community because it is not driven by service level agreements,” says Channesh Shivaprakash, Rimini Street director of technology for EMEA and Latam. “The community may be fast in responding, or it may not be, all depending on the mood of individual contributors.”
That’s why many organizations opt for paid technical support from qualified organizations.