Questions to ask when migrating to a new database platform
As systems come online and new technologies are made available, companies are faced with a decision point: Should we fragment our existing technology stack to attempt to take advantage of these new tools, or continue with our current environment at the risk of missing out on functionality? This post will give insight into the questions and concerns we often hear when a company is considering changing to a new database platform.
New database platform
The first set of questions are focused around answering our main question: What will be the primary benefit to the company by making this move to a new database platform?
Will there be significant cost savings?
At Pythian, this is often the case when we see companies moving from Oracle to SQL Server, as the licensing costs are dramatically lower (or free if they're taking advantage of a deal.) Discussing yearly savings of millions of dollars will generally get the attention of most executives very quickly.
Is there a required feature in the new database?
As a SQL Server DBA, I do sometimes look at MySQL's master-master replication or Oracle's Materialized View scheduling feature with envy. In the case of a killer feature, there's a benefit to using the built-in processes. These will be better supported, more wide-spread knowledge will be available, and it may be easier to manage once in Production.
Is this an attempt to standardize the stack?
Occasionally, a company will decide to move to a new database and find it doesn't meet their needs, or the new platform isn't worth the hassle of supporting it long-term. In this case, moving back to a database you have plenty of experience in may be worth the cost of redoing the process.
What's the roadmap for this move?
Even if the answer to all of the above questions are resoundingly positive, there's little benefit to a change that will take a decade to implement. The amount of time to convert any required application/database code, jobs, processes, and training needs to be carefully weighed against the perceived benefit.
Application architecture
The next area of concern is the architecture of the applications that are running on this system.
First, we have to define which applications are in scope. Depending on the reason for the move, it may make sense to only move a subset of the applications that are running on the current data platform, while leaving the remainder where they are.
Next, developing (or re-using existing) use cases with the Application Users allows us to ensure we have the right plan in mind, and that the new data platform will actually fit our needs. For example, if we need real-time reporting from a high volume stream of data then it won't do any good to move to a MySQL System that can't handle it. This is also a great way to shake out how exactly the application will need to change in order to meet the use cases.
Finally, if the applications are making use of an ORM or other third-party systems, then ensuring they are supported on the new data platform is obviously critical.
Database stuff
Our final check is mapping out how the database features match up between the data platforms, and how they will need to change after the cut over. Some of the major areas we always check are:
- High availability
- Disaster recovery
- Advanced feature usage
- Security options
- Auditing
Sometimes it's as simple as comparing Oracle RAC to SQL Server Availability Groups and defining what features the company will lose or gain. Sometimes a deep dive into the feature sets of the new data platform is needed, and maybe custom coding, in order to ensure functionality is maintained or grown. Regardless, this section almost always requires an expert in the new data platform so nothing is missed. If you're exploring new database platforms, feel free to reach out to us with any questions you have. We're able to provide expertise in both the database platform you're currently using, as well as the ones you're considering moving to, both on-premise and in the cloud.
