For companies that want a competitive edge in today's rapidly evolving business landscape, embracing digital transformation is essential. As business needs continue to accelerate, successful organizations will continue to move away from legacy solutions and embrace open source technologies. If your business has outgrown its current database, or you’re looking to integrate open source and cloud solutions, a database migration process is essential to safely manage and transfer your data.
While pivoting from a traditional system like Oracle to a more flexible and cost-effective alternative like Postgres can be challenging, it’s a lot easier when you know what’s ahead and have a strategic plan. Our webinar series on Navigating Your Database Migration Journey can help you get started, with tips for addressing common challenges, reducing risk, lowering costs, and shortening the time required to migrate.
In the first video of our series, "Decoding Oracle Migration: Insights Into Scope and ROI," EDB’s Migration Technology Product Manager Matt Lewandowski and Technology Strategist Marc Linster discuss how to develop a migration plan and backlog and conduct an ROI analysis. Here are some of the key points:
The process isn’t about individual databases – it’s about the estate!
The first step in the migration journey is to understand your database estate. It’s important to identify the applications and the databases that support them, understand the primary use cases, and know whether apps are commercial and off the shelf or not. You’ll also want to look at data volume and the percentage of read/write transactions, the lifecycle stage, and the database technology itself to prioritize what you’ll be migrating.
Get your application teams on board
You’ll want to make sure that you have your application teams lined up because you’ll need them for functional and non-functional verification. Even if you find changes aren’t required, which is often the case, you’ll still need your application team to make sure that things work the way they should.
Some applications use multiple databases and some databases serve multiple applications. So you’ll want to consider if you have to move multiple databases and multiple schemas to support an application, or if you can move multiple applications all at once. The answers to these questions will help you establish the backlog for performing the migrations.
Consider Oracle compatibility
If you have a couple hundred databases, they tend to be interconnected. Over time, things like DB Link get established, which causes conceptual spaghetti that makes it almost impossible to move forward without a good Oracle compatible solution. With a compatible solution, you can take one database that serves one application out and move it, and the other solutions think they’re still talking to an Oracle database, when in reality it has become a Postgres database.
Identify which apps you’ll migrate first
Once you've gained a solid understanding of your database estate, the next step is pinpointing which applications you’ll transfer first. This means evaluating the complexity and effort required for each migration, along with the potential ROI.
You’ll want to determine which apps and solutions are a good fit for Postgres, what’s easy to transfer, and what the ‘don’ts’ are. For example, if you have a commercial off the shelf application and the vendor doesn’t support Postgres, even if you can make it work it's an absolute ‘don't’, because if you have a problem, you’ll be on your own.
EDB’s service team uses a compatibility assessment tool that classifies applications and their databases into tiers from very easy to very hard. This tool connects to every database to extract information about the database schema, the stored procedures, the data volumes, compatible and incompatible features and more, so you can quickly understand the complexity and effort required for a migration.
Based on our experience, over 60% of all the Oracle migrations to EDB Postgres can be done in less than 20 days, and some of them in just a few days. All it takes is to move the DDL across and then move the data. Make sure to give yourself time to transfer the data, though. Our guideline is about 50 gigabytes per hour within the same data center, though if you're on a fast network or super fast rack, you can exceed that transfer speed. The bottom line is that If you have a large state of Oracle databases, the majority can likely be moved to ETB Postgres Advanced Server rather quickly and with very little effort.
Start with easy
Just because an application is hard or very hard to move to Postgres doesn’t mean it shouldn’t be done. But we recommend starting with transferring the very easy and easy applications in order to get familiar with Postgres and build skills that will improve your migration processes. Later you can start to introduce more complex migration scenarios that have stricter or higher availability requirements, advanced replication needs, and other challenges.
Prove your migration efforts are worth it
The business case, or ROI, is really important – even for techies! That’s because it’s not just a one time estimate that gets you the budget, but the tool that shows that it's worth keeping you funded and that you're really making a difference.
If you identify 200 databases out of 500 as being suitable candidates for migration, it’ll take time to migrate those databases, and you’ll want to ensure it’s worth doing this work! As you do the work, define your ROI by documenting how much money you’ve saved the business, how much new flexibility you’ve created, how much cloud capability you’ve created by getting rid of the legacy ball and chain, and more.
"Documenting how much money you have saved the business, how much flexibility you have created, how much cloud capability you have created by getting rid of the legacy ball and chain, is really important. So the business case or the ROI is not just a one time thing that gets you the budget. It is the tool that as you work through the backlog, as you go through the sprints, is how you show that it's worth keeping you funded and that you're really making a difference."
– Marc Linster, EDB Technology Strategist
To develop your business case, you’ll need to know core counts, how much effort will be required, and the cost of labor among other things. We offer a free ROI calculator that provides a high level estimate of what you’ll save by migrating from Oracle to Postgres. You’ll also need a timeline so you can plan cash flow and return over a multi-year period. Your ROI and timeline go together, as you'll need to maintain the support of your company throughout your migration timeline, including the application teams, finance, security administrators, and more.
Build and execute a backlog
With the ROI in place and your categorizations of effort and complexity, you can start to build a backlog. This list of work for the development team prioritizes the applications you want to tackle first and identifies the schemas and databases associated with them. You’ll want to review the very easy through very hard compatibility classifications, the level of effort, and the cost estimate, and from there, you can look at what a projection of your license cost reduction will be over time, and then prioritize the work. Depending on the size and experience of your team, we encourage you to start with one to five applications.
Once you build that backlog you can just start to work through it using sprint techniques.At the end you’ll have an application that’s running on Postgres, and eventually as you go through the iterations, you’ll have more and more until you meet your objective of having your estate migrated over.
So migration is a process, but by performing the initial work of assessing your database estate, creating a backlog, and developing an ROI, you can set the stage for quick and painless migrations and gain the company support you need to accomplish them.
Watch the full webinar on demand here
Have questions on migrating to Postgres or need support? Contact us!