Zero downtime migration from Oracle to Azure SQL

 

Modernizing mission-critical Oracle applications often involves moving underlying Oracle databases into a fully managed cloud service with near zero downtime. For many organizations, Azure SQL provides the reliability, scale, and operational simplicity needed to support modern application architectures while also unlocking tighter integration with Azure analytics, security, and AI services.

The hard part was getting there. Oracle databases tend to be large, complex, with demanding high availability business SLAs, making it difficult to migrate them to Azure SQL without planned downtime, risk of data drift, or operational disruption.

To remove these barriers, Microsoft and Striim partnered together to offer a real-time migration solution built on log-based Change Data Capture (CDC). As part of the Microsoft Unlimited Database Migration Program, this solution empowers enterprises to modernize to Azure faster, with confidence, while paving the way for AI-ready architectures and long-term innovation.

This tutorial walks through the architecture, deployment steps, and best practices for Oracle to Azure SQL migrations using Striim.

Microsoft + Striim for seamless migration

The strategic partnership between Microsoft and Striim enables continuous data replication from existing databases into Azure in real time, enabling online migrations with zero downtime. Through this Unlimited Database Migration Program, customers gain unlimited Striim licenses to migrate as many databases as they need at no additional cost.

Program highlights include:

• Zero-downtime, zero-data-loss migrations across SQL Server, Oracle, MySQL, PostgreSQL, Azure SQL and more.
• Support for migration of heterogeneous, mission-critical workloads across relational and non-relational systems.

With Striim, data moves continuously via log-based CDC, reading directly from Oracle transaction logs and replicating every insert, update, and delete to Azure in real time. This minimizes impact on production systems while maintaining full data consistency during migration.

Architecture Overview

The jointly recommended architecture consists of:

1. Source: an existing Oracle instance (on-premises or hosted in another environment).
2. Processing Layer: Striim, deployed in Azure for low-latency, secure data movement.
3. Target: Azure Database for SQL (Flexible Server or Single Server)

Connectivity is established over standard Oracle (1521) and SQL (1433) ports and can also utilize other configured ports. This solution also offers Private Link support, VNets, and other native Azure networking controls to secure traffic throughout migration.

Step 1: Preparing the Oracle Source

Before replication can begin, configure Oracle so that redo logs are accessible and a CDC user can be used by Striim.

Striim supports multiple CDC methods for Oracle:

• Oracle Reader (LogMiner): Uses Oracle’s LogMiner API to read from redo logs. This is the default method.
• OJet: A high-performance CDC method, typically used for Oracle 21c or very high-volume workloads that generate large amounts of redo logs.
• GoldenGate trail files: If Oracle GoldenGate is already present, Striim can read from existing GoldenGate trail files rather than attaching another CDC process directly to the source database.

All options are log-based, ensuring CDC overhead is typically in the low single-digit percentage range.

Once chosen, ensure Striim can connect to Oracle over the JDBC listener port (default 1521). If Oracle is on-premises, this typically involves VPN/ExpressRoute or an SSH tunnel/jump host from Striim to the Oracle network before you can create a CDC user in Striim.

Creating a CDC user (example)

As an Oracle user, create a dedicated account for Striim and grant the required privileges for redo log access (exact grants may vary by version and CDC method). Please reference Striim’s Oracle CDC docs for the latest instructions:

CREATE USER striim_user IDENTIFIED BY "StrongPassword!";
GRANT CONNECT, RESOURCE TO striim_user;

-- Example privileges for redo/log views (adjust per security and Striim docs)

GRANT SELECT ANY TRANSACTION TO striim_user;
GRANT SELECT ON V_$LOG TO striim_user;
GRANT SELECT ON V_$LOGFILE TO striim_user;
GRANT SELECT ON V_$ARCHIVED_LOG TO striim_user;
GRANT SELECT ON V_$DATABASE TO striim_user;

Once the user is created and networking is in place, Striim can be configured to connect to Oracle using a JDBC URL such as:

jdbc:oracle:thin:@//<oracle-host>:1521/<service_name>

Step 2: Preparing Azure SQL

On the target side, you must provision the right Azure SQL target and ensure schema, networking, and permissions are in place before starting data movement.

Schema creation

Prior to starting the data movement pipelines, create tables in Azure SQL corresponding to those in the Oracle source. This can be done with:

• SQL Server Migration Assistant for Oracle: Helps with the conversion and deployment of Oracle schema objects including tables, views, indexes and also helps with converting the programmatic SQL objects like PL/SQL procedures, functions and packages.
• Striim’s Schema Conversion Utility (CLI): Generates SQL DDL for the target system based on Oracle metadata.
• Striim’s wizard-based schema creation: Creates target tables directly from the Striim UI during pipeline configuration.External tools: You can also use existing schema migration utilities or custom DDL as required.

Permissions

Create an Azure SQL user for Striim with write privileges on the target tables. Here is an example script to create a user on Azure SQL:

CREATE USER striim_user WITH PASSWORD 'strongpassword';

GRANT INSERT, UPDATE, DELETE, SELECT ON ALL TABLES IN SCHEMA public TO striim_user;

ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT INSERT, UPDATE, DELETE, SELECT ON TABLES TO striim_user;

Striim will use this user when running Database Writer components against Azure SQL.

Step 3: Building the migration pipeline

A complete Oracle to Azure Database for SQL migration typically includes three coordinated stages:

1. Schema Migration – Create equivalent tables and objects in Azure SQL.
2. Initial Load – Bulk-load historical data from Oracle into Azure.
3. Change Data Capture (CDC) – Continuously stream real-time transactions, keeping source and target in-sync until production cutover.

Initial load & continuous stream

Once the schema is in place using one of the methods above, you can configure Striim to first bulk-load historical data, then switch to continuous CDC.

During the initial load, Striim uses a Database Reader component to extract full tables from Oracle, and a Database Writer component to load them into Azure SQL. The Striim applications can be built through a drag-and-drop interface, a wizard, or through a text-based interface, shown below.

The Database Writer uses a user-defined batch policy to control how data is written. By default (e.g., EventCount:1000, Interval:60s), Striim will write to SQL when either 1,000 events are accumulated or 60 seconds have passed, whichever happens first.

A conceptual example of an initial-load configuration using TQL might look like:

CREATE SOURCE OracleInitialLoadReader USING DatabaseReader (
    Username:'striim_user',
    Password:'strongpassword',
    ConnectionURL:'jdbc:oracle:thin:@//oracle-host:1521/ORCL',
    Tables:'HR.EMPLOYEES'
);

CREATE TARGET SQLInitialLoadWriter USING DatabaseWriter (
    Username:'striim_user',
    Password:'strongpassword',
    ConnectionURL:'jdbc:SQL://pg-host:5432/mydb',
    Mode:'Insert',
    BatchPolicy:'EventCount:10000,Interval:30s'
)
INPUT FROM OracleInitialLoadReader;

Continuous CDC stream

After the initial load completes, Striim switches to a CDC pipeline that applies new Oracle transactions in real time until cutover. The CDC pipeline uses an Oracle CDC reader (Oracle Reader, OJet, or GoldenGate trail reader) and a Database Writer targeting Azure SQL.

A CDC example in T-SQL could look like:

CREATE SOURCE OracleCDCReader USING OracleReader (
    Username:'striim_user',
    Password:'strongpassword',
    ConnectionURL:'jdbc:oracle:thin:@//oracle-host:1521/ORCL',
    Tables:'HR.EMPLOYEES'
);

CREATE TARGET SQLCDCWriter USING DatabaseWriter (
    Username:'striim_user',
    Password:'strongpassword',
    ConnectionURL:'jdbc:SQL://pg-host:5432/mydb',
    Mode:'UpdateOrInsert',
    BatchPolicy:'EventCount:1000,Interval:60s'
)
INPUT FROM OracleCDCReader;

To ensure zero data loss, follow the sequencing guidelines in Striim’s documentation for switching from initial load to continuous replication.

Cutover

When the Azure SQL environment is fully synchronized, and you are ready to move applications off Oracle:

 

1. Pause writes to Oracle. Temporarily stop application writes to the source.
2. Validate record counts. Compare row counts (and optionally checksums or spot checks) between Oracle and Azure SQL. Striim has recently released a new tool called Validata to automatically do this. Please reach out to learn more.
3. Redirect application traffic to Azure SQL. Update connection strings so applications now point at the Azure SQL instance.
   
   

Because Striim’s CDC keeps the source and target continuously in sync, the cutover window is typically very short, minimizing or eliminating downtime for end users.

Adding Transformations and Smart Data Pipelines

Beyond one-to-one replication, Striim allows you to enrich, transform, and validate data in flight using continuous SQL queries or custom Java processors. For example, you can append metadata for auditing:

SELECT *, CURRENT_TIMESTAMP() AS event_time, OpType() AS operation FROM SQLServerStream;

These Smart Data Pipelines enable in-stream transformations (e.g., deduplication, validation, or enrichment) without separate ETL jobs, streamlining modernization into a single continuous flow.

Performance Expectations

In joint Striim–Microsoft testing:

• 1 TB historical load typically completed in 4–6 hours, which can be further performance-tuned to decrease initial load time.
• CDC replication latency averages sub-second for inserts, updates, and deletes.
  
  

Performance depends on schema complexity, hardware, and network configuration. For optimal results:

 

• Deploy Striim in the same Azure region as the target.
• Use private networking.
• Allocate adequate CPU and memory to handle peak CDC throughput.

Support and Enablement

The Microsoft Unlimited Database Migration Program is designed specifically to provide customers direct access to Striim’s field expertise throughout the migration process.

From end-to-end, you can expect:

• Onboarding and ongoing support, including installation kits and walkthroughs.
• Higher-tier service packages are available as well.
• Direct escalation paths to Striim for issue resolution and continuous assistance during migration and replication.
• Professional services and funding flexibility, such as ECIF coverage for partner engagements, cutover or weekend go-live standby, and pre-approved service blocks to simplify SOW approvals.
  
  

Together, these resources ensure migrations from Oracle to Azure DB for SQL are fully supported from initial enablement through post-cutover operations, backed by Microsoft and Striim’s combined teams.

Whether your goal is one-time migration or continuous hybrid replication, Striim’s CDC engine, combined with Azure’s SQL Database, ensures every transaction lands with integrity. Start your modernization journey today by connecting with Striim directly through your Microsoft representative.