michelangelus - Fotolia
Open source database migration guide: How to transition
Open source database transitions have been on the rise as they prove to be worthy competitors to commercial database options, but that transition requires strategy and user buy-in.
Companies are transitioning from commercial databases to community-oriented open source databases because of the maturity and economic benefits.
Open source database migration typically involves more than just a database. 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. Beyond the database ecosystem, application integration with the database may be impacted as well.
The appeal of open source databases, particularly for smaller non-mission-critical systems, has led to increased adoption and market popularity.
Why choose an open source database?
Perhaps the most compelling reason for open source database migration is total cost of ownership savings due to the lack of licensing cost and potential support savings. Open source databases have also reached a maturity level where they provide features and capabilities to power many enterprise workloads that rival commercial database offerings.
An open source database can alleviate vendor lock-in dependencies to provide future flexibility. A growing number of technologists are attracted to open source simply for its values, including open exchange, collaboration, transparency, meritocracy and community.
Transition models
Some companies can simply replace existing commercial databases with open source counterparts. More than likely, you will still retain some commercial database implementations, as open source options are often playing catch-up with commercial products.
If you need the latest innovations or high-end features, your best option may be a commercial database along with an open source database that complements its offerings. This approach provides a lower-cost option for the majority of database deployments while reducing the footprint of commercial databases, which can be reclassified as special purpose. A multimodel open source database that supports diverse data models can keep your database portfolio in check.
Transition strategy
The transition strategy is to steer your workload to open source databases where it makes sense. Don't look to immediately throw away investments in commercial databases; just be smart about it.
One tactic is to approach open source database migration in waves. The first wave will direct new database implementations to open source. The second wave will look for opportunities to transition existing commercial databases to open source alternatives.
Database transitions are typically not a simple migration exercise of porting existing applications and databases. Incompatibilities between database products often make it necessary for varying levels of migration, conversion and refactoring. A playbook can help provide a step-by-step guide to evaluate risk, cost, compatibility and complexity of database transitions.
Assessment areas
Assessments should consider people, processes and technology involved in the transition and subsequent operations. For this, you'll need to discover and analyze the commercial and open source database ecosystems. Take time to identify the tools and utilities to automate this phase where possible.
These are the top assessment areas to consider in your open source database migration.
Financial. Understand the total cost of ownership for open source databases. Estimate direct and indirect costs, including the transition cost, operational expenses and long-term retirement. Be sure to factor in the cost of retiring existing commercial databases, as this can be expensive.
Database replacement. Rationalizing a move from a core technology can be challenging. This is magnified with widespread use and support for critical systems. Develop an open source database migration road map to put the effort into perspective. A transition timeline can also gain buy-in from impacted system users upstream and downstream from the database.
Community. Look beyond the database for an active community that embraces open source values, diverse contributions and a track record of continuous maturation. Good indicators of a healthy community include user groups, mailing lists, websites, blogs, events, documentation and support channels. Pay particular attention to the governance model, and look for community representation in setting the project direction.
Hosting and compute model. Ensure the desired hosting provider offers the open source database and understand the computing models -- SaaS, PaaS and IaaS -- as well as availability and scalability configuration options.
Application and integration. Confirm that the open source database and applications, programing languages and interfaces are compatible, preferably certified and supported. Control of source code is an important factor; in-house applications will make it easier for modifications, and open source or third-party commercial products may be more difficult or impossible to modify.
Schema (non-programming objects). Generally speaking, open source databases that adhere to industry standards make transitioning database schemas a straightforward process. The effort is largely determined by the number and types of database objects.
Database code (programming objects). Transitioning database code in the form of packages, triggers, stored procedures, functions and statements is typically the most time-consuming and underestimated effort. Expect some migrated code to require manual resolution for equivalent functionality or performance due to differences in database programming languages. In some cases, such as product-specific extensions to database language, functionality might not be available or may require modified application logic.
Features and capabilities. Commercial and open source databases continue to differentiate themselves in their features. Identify database characteristics and behaviors that migrate without modification, have a compatible implementation or are simply unsupported -- in some cases, with potential substitutions.
Performance. Open source databases can typically satisfy most enterprise workloads and performance requirements. Some high-performance applications might need manual tuning to optimize performance, but open source alternatives may lack the tuning knobs of commercial databases.
Security. Most leading open source databases provide basic user, role and privilege management. They may lack advanced security features, such as password management and data encryption in transit and at rest. Understand your security controls and look for equivalent safeguards in the open source database to minimize risk.
Tooling. Automated tools and migration services are often available to assist the transition, but you should plan for some manual conversion as well as review and testing. The level of effort and compatibility of a transition is largely dependent on the size and complexity of a database. Once transitioned, be sure to consider database add-ons that fill capability gaps.
Support. Understand the availability of database ecosystem support for the transition and subsequent operations. Consider internal training, new hires and external professional services. Unless you have a strong internal support team, consider commercial support if the database is mission-critical. Also evaluate if the cadence of database updates and releases aligns with your company's needs.
Licensing. Know the open source database licensing terms and associated risks. Some databases are community owned and controlled through a community governance model. Other databases are owned by a corporate entity that distributes periodic releases of the code base using an open source license. When a single entity controls the intellectual property, it may change licensing terms or take the product in a different direction without community input. Previous releases remain open source and property of the community.
