With cloud deployments there is increasingly a general business-led impetus, to choose ‘one cloud’.  This is to reduce complexity, perhaps costs, enforce standardisation and simplification.  There are merits and demerits to this approach.  One obvious disadvantage is vendor lock-in, but there are technical issues which may preclude a native or easy migration of an IT stack or application stack to a particular platform.

For example, you may see a VLE (very large enterprise) decide that they will deploy their business applications ‘only’ on Azure, regardless of the application-stack or underlying technologies.  This is usually a ‘business’ not a technical decision which could infer and incur some serious technical constraints.  The business may love Azure since Microsoft is giving away its services free or heavily discounted.  The technical group, however, may state that some workloads and application stacks best belong in different clouds and that forcing Oracle (say RAC) onto Azure, is imprudent.

In this scenario you would move Oracle to AWS or perhaps the Oracle cloud, depending on your future strategy.  For instance, if you eventually want to move off Oracle and into Aurora (to save massive license fees), you would first re-platform Oracle to AWS, then set up a migration plan to Aurora.  However, ‘free’ is compelling for those with calculators and sharp pencils and they may decree to the lowly IT food chain, that Azure is the ‘main platform’.  If the pointy-IT heads rightly state that Oracle license reduction provides a massive ROI, the pencil-people will declare that the Azure ROI is now, whilst the Oracle premised ROI is in the future. 

Recent experience with the above is summarised below.  There is a method to move Oracle (but not RAC) which necessitates a 3rd party layer) onto Azure. 

Business Demands

  1. Migrate Oracle databases (upgraded to the latest version before-hand), non-RAC estate, to Azure
  2. Migrate current Oracle databases to Azure SQL database PaaS depending on the use case and testing results
  3. Also assess migrating the Oracle databases to Azure on VMs (IaaS) and self-managing the DBs

It may be that you will end up with a mix of PaaS and IaaS.  The operational model to support IaaS needs to be well thought out before you migrate. 

 

Technical Translations

Oracle is not ‘native’ on Azure.  The following sections present some steps to overcome these challenges.  Keep in mind that you need to prepare your Azure estate to receive the Oracle migration properly.  DBA setup steps must be followed in their entirety.

Of course, you need to properly scope the project, set up an agile team composed of key stakeholders and skillsets, create an HLD, including the main principles of security of the stack, networking architecture, data encryption, end user access, SSO etc.  There is usually networking and load issues with Oracle on Azure, when connecting from on-premise or a non-Azure network, so check the following:

The following is the general approach (source Azure).

 

Use the Right Tools

Azure has migration assistants that you need to use to understand which PaaS or IaaS configuration you will need (SQL Server vs Azure SQL). 

If you are using advanced Oracle features that may not be supported in Azure, or with SQL Server 2017-2019, use the Oracle Extension Pack which will emulate these features in an Azure DB.  This will include materialized-views and object-redesign.  There are of course issues with emulation (latency) and technical trade-offs which should be documented and understood (in the HLD, and eventually the E2E).

Migrate 1 DB and patiently optimise

Migrate your first non-critical DB using native Oracle or Azure tools.  Use the virtualised environments to improve your tools usage and look at more advanced automation if needed for application-development, testing and deployment.  Usually you lift and shift first, re-platform, engage the steady state, optimise and add automation and tools over time.  Don’t expect to create an automated pipeline in a short period of time. 

Perform Tests and Compare by transaction Duration

Part of testing an Oracle application is to test for duration time.  Oracle and Azure have optimisers to test latency based on transaction duration.  Use these to understand performance differences.  Azure also has an ‘advisor’ which can be very helpful in optimising the Oracle database, and isolate issues with duration.  A key issue with Oracle DBs in Azure is that some firms don’t adequately test for duration (network, access, bandwidth, data loads, data transfers, interaction with the application, Web Logic issues etc.)

Read the Azure documentation

Azure and Oracle have a lot of documentation on moving an Oracle platform into Azure-cloud.  The following are key links that should be used.

Microsoft Planning Assessment Tool Kit

Planning tool and assessment toolkit.                                                

SQL Server Migration Assistant, (Hybrid) for Oracle

Connect to Oracle databases and report/migrate Oracle databases to SQL Server or Azure

SSMA Oracle Extension Pack

Identified Oracle centric features and emulates them in Azure.

Support Document for SSMA Oracle Extension Pack

Support document to assist in installing and configuring

Licensing Document for Oracle to Azure

Always complicated, find a pricing expert to help

 

Some other links to help optimise the migration approach are given below.

Oracle Snap Clone Copy

Virtual Database Clones allows for large RDBMS to be migrated almost as fast an application.

 

Creating Read and Write Snapshots

Virtualization Example that will save on time and storage for initial testing without extensive downtime

 

Azure Test Plans

Ability to test workloads and benchmark progress

 

Azure Advisor

Identifies and make recommendations across multi-tier environments

 

===END