Migrating Oracle Databases to Azure

Cloud is a still a huge buzz word because people are still moving to embrace it. As many companies that are in the cloud, there are still a large percentage of real estate that’s on-premises. As much as I’m now Analytics and AI with Azure, it shouldn’t surprise anyone that I’ve been adopted by a number of those inside Microsoft to assist in the migration of Oracle databases to Azure. There are three primary goals:

1. Move to the cloud and Azure is their cloud choice, so they plan on staying with the Oracle database platform.
2. Migrate current Oracle databases to Azure SQL database, (or other offering.)
3. Or they will move their Oracle databases to Azure on VMs and need to plan accordingly to ensure they can migrate on a future date.

Just like someone who’s bilingual, I forget that the “translations” between the platforms aren’t that straight forward for others and that a little bit of help can go a long way. Hopefully the following, although high level, will assist anyone who’s facing this challenge.

Scope Out the Project

A good plan is important if you want to succeed. If you just start moving everything without a plan, you’re going to have problems.

1. List out everything that will need to be moved.
2. Identify versions, connected applications and prioritize how critical the application, database, etc. are to the organization. Start with lesser impacting applications first and move onto more critical ones last.
3. Along with testing workloads in the cloud, TEST THE NETWORK. Bandwidth and latency on the network is the most impacting change in every cloud migration project I’ve been part of.
4. Identify processes that currently require heavy demands on network- You are looking for those applications that weren’t dependent on a data source being in the cloud previously and may need to rethink the way they currently perform their work. Optimize before going to the cloud on any “low-hanging fruit” to remove these constraints and reallocate resources to the unexpected demands that will result once you do move. It’s always the unexpected that happens and you should prepare for the worse. Its better to report you’ve addressed something than explain why you weren’t prepared.
5. Involve all the participants- development, operations, database administrators, end users, business owners and network administrators. Everyone that has is a stakeholder in the success of the project should be part of the project- FROM THE BEGINNING.

Use the Right Tools

Azure has migration assistants that will support multiple platforms that wish to perform an assessment to Azure, (or SQL Server on-premises.) Utilize the SQL Server Migration Assistant, (SSMA) to perform a discovery and assessment, which will report on the current environment, including schemas, code and if there are any issues.

For those of you who have advanced features in Oracle that you assumed wouldn’t be supported in Azure, (or SQL Server 2017-2019) there’s the Oracle Extension Pack, which emulates these features in an Azure database. This includes Oracle materialized views and other object redesign that will need to be “simulated”.

Once you’ve migrated one database, begin to use virtualized environments to lessen the demands on archaic tools as you lift and shift, then use more advanced app/dev automation to speed up the testing and deployment process with Azure DevOps, including features like Test Plans, Pipelines and products from the Extensions Marketplace.

Perform Tests and Compare by DURATION

“Test for Time or You’re Wasting Time.” Nuff’ said. Oracle, Azure and SQL Server all have cost based optimizers and all three offer you metric and latency information based on duration. Use it to address differences in performance, no matter what platform or cloud you’re going to. The Azure Advisor can offer significant information on performance in the cloud and you should already have AWR reports to compare durations from the on-premises versions to isolate issues. All those stakeholders should be engaged as part of all phases of this project and signing off on each phase. One of the differences that you’ll notice in my diagram of a migration from most, is that I pull “Optimize” back to just after the “Validate” step in the project, where most people put it to the end.

Once you’re up in the cloud, test, optimize some more and review. Once you’re satisfied, then you can begin to deprecate on-premises environments and get the full benefit of the cloud.

If you want to know more about how to migrate Oracle to Azure, (and these links will take you to pages for migrating other platforms like Postgres and MySQL, too) check out the following links. As there are still questions on licensing of Oracle on Azure, I included the link to the vCPU licensing, too:

 

If you’re interested in reading up on what features in Oracle and Azure can help outside of the actual migration steps to ease testing and refreshes, check these links out: