Migrate Business Critical Applications to Oracle Database@Azure Using a Phased Strategy

Migrate an on-premises database and application to the cloud, minimizing downtime with phased or hybrid strategies, ensuring seamless connectivity for cloud-based apps to on-premises databases. A well-structured plan accelerates data center exit, mitigates risks, and maintains reliability. A hybrid, two-phased approach enables smooth transition while maintaining stability.

When moving an on-premises database and application to the cloud, you must address several challenges to ensure a seamless transition. Choose a migration strategy that minimizes downtime, such as phased migration or hybrid cloud solutions, to maintain application up-time, especially for critical business workloads. Ensure that applications already in the cloud, which connect to on-premises databases, are also considered in the migration plan to avoid connectivity issues. For SaaS applications, where the app resides in the cloud, but the database is on-premises, ensure a comprehensive strategy that includes both components. Address these challenges proactively to ensure a smooth transition and maintain the reliability of your critical business applications. A well structured strategy also helps you expedite data center exit and reduce migration risks, ensuring the reliability of your critical business applications.

Oracle Database@Azure eliminates the reliance on on-premises Exadata or Oracle Real Application Clusters (Oracle RAC) by bringing the database closer to application workloads within Microsoft Azure. This integration enables both the database and applications to be hosted in the same data center, reducing latency and minimizing dependence on physical infrastructure.

Implementing this setup often requires a carefully designed solution to establish the target architecture without disrupting critical business operations. Many mission-critical workloads are deployed across multiple regions to ensure business continuity through disaster recovery or standby environments. This approach supports a hybrid, two-phase migration strategy, allowing seamless transitions while maintaining operational stability.

Before You Begin

Before you begin, ensure you consider the following:

  • Disable Fast-Start Failover in Oracle Data Guard to ensure a smooth and controlled transition between the primary and standby regions during migration.
  • OCI Database Migration provides validated, cross-version, fault-tolerant, and incremental Oracle Database and MySQL migrations for online and offline use cases, such as ZDM and OCI Migration.
  • This reference architecture follows the Oracle Gold Maximum Availability Architecture (MAA) model in an active-standby configuration with cross-region deployment for enhanced resilience. This reference architecture can be extended to use MAA platinum, where local high availability is achieved through synchronous replication using Oracle Data Guard between availability zones, while cross-region disaster recovery is implemented with asynchronous replication.

Architecture

This architecture outlines a phased approach for migrating on-premises Oracle Database onto Oracle Exadata Database Service at Oracle Database@Azure with minimal downtime.

To simplify this strategy, we break it down into three key aspects: current state, future state, and migration phases.

This reference architecture has four primary components (marked with blue numbers in diagram).
Number Component Description
1 On-premises primary data center Hosts the database and application as the primary system before migration.
2 On-premises standby data center Maintains a standby system, replicating the on-premises primary database.
3 Azure primary region Runs the application and database on Oracle Database@Azure, becoming the primary system post-migration.
4 Azure standby region A disaster recovery site replicating the primary region using Oracle Data Guard.


logical-architecture-diagram-oracle.zip

Current state

In the existing setup, both the primary data center (1) and standby data center (2) are hosted on-premises, supporting application workloads and databases. The primary data center handles all requests, while the standby data center maintains asynchronous replication using Oracle Data Guard. This ensures high availability, with the standby system ready for failover in case of unexpected failures.

Future state

The future architecture mirrors the current setup but is fully hosted in the cloud, spanning two Azure regions: the primary region (3) and the standby region (4). The database is migrated to Oracle Database@Azure Exadata services, with asynchronous replication between the primary and standby databases managed via Oracle Data Guard over the Oracle Cloud Infrastructure (OCI) network.

For secure connectivity between the on-premises data center and Azure, an Azure Firewall is deployed within a secure Virtual WAN (vWAN) Hub in Azure.

Migration phases

The migration follows a two-phase approach to ensure a controlled and reliable transition.

Phase 1 – Transitioning on-premises standby to Azure and switchover

In this phase, the on-premises standby system (2) is migrated to Azure (3). Once completed, the primary (1) and standby (3) roles are swapped, making Azure the new primary region.

  1. Establish connectivity between on-premises and Azure using Azure ExpressRoute.
  2. Configure Azure secure hub, Azure Firewall, and vWAN for security (if not already in place).
  3. Provision Oracle Exadata Cloud Infrastructure in Azure’s primary region, then:
    1. Set up an Oracle Exadata virtual machine (VM) cluster and create the target database.
    2. Enable archive logs and forced logging on the primary database (if not already enabled).
  4. Configure Oracle Net for listener and TNS names for discovery.
  5. Restore from service to set up a standby database in Azure’s primary region (3).
  6. Perform a switchover, making the Azure database (3) the new primary.
  7. Migrate applications to the Azure primary region (3) and update DNS routes.
  8. Verify the Data Guard configuration and monitor the replication status.

Phase 2 – Establishing standby in Azure and decommissioning on-premises

In this phase, a standby system (4) is set up in Azure, and on-premises resources (1 and 2) are decommissioned.

  1. Provision Oracle Exadata Cloud Infrastructure in the standby region (4) with Oracle Database@Azure.
  2. Set up an Oracle Exadata VM cluster and create the standby database.
  3. Enable Oracle Data Guard to associate the primary region database (3) with the standby database (4).
  4. Use OCI networking for high-throughput replication, leveraging local and remote peering within a hub-and-spoke topology between the primary and standby databases.
  5. Migrate application workloads to the Azure standby region (4).
  6. Stop the synchronization with the on-premises resources and then decommission the on-premises application and database resources from the primary (1) and standby (2) data centers.

The following diagram illustrates this reference architecture.



physical-architecture-diagram-oracle.zip

Microsoft Azure provides the following components:

  • Azure Region

    An Azure region is a geographical area in which one or more physical Azure data centers, called availability zones, reside. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

    Azure and OCI regions are localized geographic areas. For Oracle Database@Azure, an Azure region is connected to an OCI region, with availability zones (AZs) in Azure connected to availability domains (ADs) in OCI. Azure and OCI region pairs are selected to minimize distance and latency.

  • Azure Availability Zone

    Azure availability zones are physically separate locations within an Azure region, designed to ensure high availability and resiliency by providing independent power, cooling, and networking.

  • Azure VNet

    Microsoft Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure virtual machines (VM), to securely communicate with each other, the internet, and on-premises networks.

  • Azure Delegated Subnet

    Subnet delegation is Microsoft's ability to inject a managed service, specifically a platform-as-a-service (PaaS) service, directly into your virtual network. This allows you to designate or delegate a subnet to be a home for an external managed service inside of your virtual network, such that external service acts as a virtual network resource, even though it is an external PaaS service.

  • Azure VNIC

    The services in Azure data centers have physical network interface cards (NICs). Virtual machine instances communicate using virtual NICs (VNICs) associated with the physical NICs. Each instance has a primary VNIC that's automatically created and attached during launch and is available during the instance's lifetime.

  • Azure Virtual Network Gateway

    Azure Virtual Network Gateway establishes secure, cross-premises connectivity between an Azure virtual network and an on-premises network. It allows you to create a hybrid network that spans your data center and Azure.

  • Azure Virtual WAN

    Microsoft Azure Virtual WAN (VWAN) is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface.

  • Azure Secure Hub

    An Azure secure hub, also known as a secured virtual hub, is an Azure Virtual WAN hub enhanced with security and routing policies managed by Azure Firewall Manager. It simplifies the creation of hub-and-spoke and transitive network architectures by integrating native security services for traffic governance and protection. This setup automates traffic routing, eliminating the need for user-defined routes (UDRs). Organizations can use a secure hub to filter and secure traffic between virtual networks, branch offices, and the internet, ensuring robust security and streamlined network management.

  • Azure Firewall Manager

    Azure Firewall Manager is a centralized security management service that simplifies the deployment and configuration of Azure Firewall across multiple regions and subscriptions. It allows for hierarchical policy management, enabling global and local firewall policies to be applied consistently. When integrated with Azure Virtual WAN (vWAN) and a secure hub, Azure Firewall Manager enhances security by automating traffic routing and filtering without the need for user-defined routes (UDRs). This integration ensures that traffic between virtual networks, branch offices, and the internet is securely managed and monitored, providing a robust and streamlined network security solution.

  • Azure ExpressRoute

    Azure ExpressRoute is a service that enables private connections between on-premises data centers and Microsoft Azure, bypassing the public internet. This results in higher security, reliability, and faster speeds with consistent latencies. ExpressRoute connections can be established through a connectivity provider using various methods such as point-to-point Ethernet, any-to-any (IP VPN), or virtual cross-connections. When integrating with on-premises data centers, ExpressRoute allows seamless extension of your network into the cloud, facilitating hybrid cloud scenarios, disaster recovery, and data migration with enhanced performance and security.

Oracle Cloud Infrastructure provides the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, hosting availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domain

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain shouldn't affect the other availability domains in the region.

  • Virtual cloud network (VCN) and subnet

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Route table

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

  • Security list

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that is allowed in and out of the subnet.

  • Network security group (NSG)

    NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of Oracle Cloud Infrastructure you control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of VNICs in a single VCN.

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service is an Oracle Cloud service that protects Oracle databases. Backup automation and enhanced data protection capabilities for OCI databases allow you to offload all backup processing and storage requirements to Oracle Database Autonomous Recovery Service, which reduces backup infrastructure costs and manual administration overhead.

  • Exadata Database Service

    enables you to leverage the power of Exadata in the cloud. Oracle Exadata Database Service delivers proven Oracle Database capabilities on purpose-built, optimized Oracle Exadata infrastructure in the public cloud. Built-in cloud automation, elastic resource scaling, security, and fast performance for all Oracle Database workloads helps you simplify management and reduce costs.

  • Oracle Database@Azure

    Oracle Database@Azure is the Oracle Database service (Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Autonomous Database Serverless) running on Oracle Cloud Infrastructure (OCI), deployed in Microsoft Azure data centers. The service offers features and price parity with OCI. Purchase the service on Azure Marketplace.

    Oracle Database@Azure integrates Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC), and Oracle Data Guard technologies into the Azure platform. Users manage the service on the Azure console and with Azure automation tools. The service is deployed in Azure Virtual Network (VNet) and integrated with the Azure identity and access management system. The OCI and Oracle Database generic metrics and audit logs are natively available in Azure. The service requires users to have an Azure subscription and an OCI tenancy.

    Autonomous Database is built on Oracle Exadata infrastructure, is self-managing, self-securing, and self-repairing, helping eliminate manual database management and human errors. Autonomous Database enables development of scalable AI-powered apps with any data using built-in AI capabilities using your choice of large language model (LLM) and deployment location.

    Both Oracle Exadata Database Service and Oracle Autonomous Database Serverless are easily provisioned through the native Azure Portal, enabling access to the broader Azure ecosystem.

  • Data Guard

    Oracle Data Guard and Oracle Active Data Guard provide a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases and that enable production Oracle databases to remain available without interruption. Oracle Data Guard maintains these standby databases as copies of the production database by using in-memory replication. If the production database becomes unavailable due to a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Oracle Active Data Guard provides the additional ability to offload read-mostly workloads to standby databases and also provides advanced data protection features.

  • Local peering

    Local peering enables you to peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network.

  • Remote peering

    Remote peering allows resources within different VCNs to communicate using private IP addresses. Remote peering eliminates the need for an internet gateway or public IP addresses for instances that need to communicate with another VCN in a different region.

  • Hub virtual cloud network

    A hub virtual cloud network (VCN) acts as a central point for managing and routing traffic between multiple VCNs, both within the same region and across different regions. Using local peering gateways (LPGs), the hub VCN connects to multiple spoke VCNs within the same region, facilitating efficient communication and centralized management. For cross-region connectivity, remote peering groups (RPGs) are used, where each VCN attaches to a Dynamic Routing Gateway (DRG) and establishes remote peering connections (RPCs). This setup is particularly useful for routing Oracle Data Guard traffic, ensuring that redo logs and other synchronization data are efficiently transmitted from the primary database in one region to the standby database in another region, thereby maintaining data consistency and high availability.

The on-premises system has the following components:

  • Primary data center

    An on-premises data center hosting applications and an Oracle database serves as the primary site for business operations, ensuring high performance and data availability. To enhance disaster recovery and business continuity, this primary data center is associated with a standby data center, often located in a different geographical region. The standby data center maintains a synchronized copy of the Oracle database using Oracle Data Guard, which continuously replicates changes from the primary database to the standby database. In the event of a failure or disaster at the primary site, the standby data center can quickly take over, minimizing downtime and data loss, thereby ensuring uninterrupted business operations.

  • Standby data center

    A standby data center is a critical component of a disaster recovery strategy, designed to ensure business continuity in unforeseen conditions. It hosts a replica of the primary applications and Oracle Database, kept in sync through technologies like Oracle Data Guard. In the event of a failure or disaster at the primary data center, the standby data center can seamlessly take over operations, minimizing downtime and data loss. This setup ensures that business processes continue to run smoothly, providing resilience against disruptions and maintaining service availability for users and customers.

  • Database

    An Oracle database hosted in an on-premises data center plays a crucial role in storing and managing business data. It provides a secure, high-performance environment for handling critical business operations, ensuring data integrity and availability. This setup allows organizations to maintain full control over their data infrastructure, customize configurations to meet specific needs, and comply with regulatory requirements. By leveraging Oracle's robust database features, businesses can efficiently process transactions, generate reports, and support decision-making processes.

  • Applications

    Applications running in an on-premises data center on top of an Oracle database are integral to business operations. These applications leverage the robust and reliable Oracle database to process transactions, manage customer data, and generate critical business insights. By operating within a secure and controlled environment, they ensure high performance, data integrity, and compliance with regulatory standards. This setup allows businesses to customize their infrastructure to meet specific needs, providing a stable foundation for day-to-day operations and strategic decision-making.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.

Performance

An OCI network is strongly recommended for disaster recovery (DR) replication. OCI's high-performance network infrastructure ensures low-latency, high-bandwidth connectivity, which is essential for efficient data replication and synchronization between the primary and standby databases. Leveraging OCI networking for Oracle Data Guard with Oracle Database@Azure offers significant advantages in performance, security, and reliability.

This setup strengthens DR by enabling fast and secure transmission of redo logs and critical data, minimizing data loss and downtime during fail over scenarios. Additionally, OCI’s built-in security features, including network encryption and advanced access controls, provide robust protection for sensitive data.

By integrating OCI networking with Oracle Database@Azure, organizations can achieve a seamless, resilient, and highly available database architecture that enhances business continuity and operational efficiency.

Considerations

Consider the following points when deploying this reference architecture.

  • Business continuity

    Integrating Oracle Database Autonomous Recovery Service with Oracle Data Guard creates a comprehensive and resilient data protection strategy for primary and standby database setups. Oracle Data Guard ensures high availability and disaster recovery by maintaining a synchronized standby database that can take over in the event of a primary database failure, thereby minimizing downtime and data loss.

    Complementing this, Oracle Database Autonomous Recovery Service provides a fully managed, centralized backup solution with zero data loss protection and real-time recovery capabilities. This combination ensures continuous data protection through both real-time replication and robust backup mechanisms, enhancing data integrity and business continuity.

  • Availability

    Deploying multiple Oracle Database instances across different availability zones (AZs) within a region, along with Active Data Guard, significantly improves high availability and disaster recovery capabilities. AZs are isolated from each other, ensuring that failures in one does not impact others. By distributing database instances across multiple AZs, organizations can mitigate risks associated with localized failures such as power outages or hardware issues.

    Active Data Guard further strengthens this setup by maintaining a real-time synchronized replica of the primary database, enabling seamless fail over in case of a primary instance failure. This approach ensures continuous data protection, minimal downtime, and a robust disaster recovery strategy, providing a resilient infrastructure for mission-critical applications.

  • Throughput

    When migrating databases from on-premises to Azure, it's crucial to consider the bandwidth of Azure ExpressRoute to ensure a smooth and efficient transfer. For instance, if you're migrating a small database of 100 GB, a 200 Mbps ExpressRoute circuit can handle the transfer in approximately 1 hour and 10 minutes, assuming optimal conditions and no overhead. However, for a larger database of 1 TB, the same 200 Mbps circuit would take around 11 hours and 40 minutes. Upgrading to a 1 Gbps circuit would significantly reduce this time to about 2 hours and 20 minutes. Plan accordingly so that the entire bandwidth is not consumed; otherwise, other applications communicating between on-premises and cloud may be impacted.

Acknowledgments

  • Authors: Neeraj Tyagi, Thomas Van Buggenhout
  • Contributors: Emiel Ramakers, John Sulyok