Zero downtime migration from Oracle to Azure DB for PostgreSQL
Co-authored by: Maxim Lukiyanov, Principal PM Manager, Postgres on Azure, Microsoft Edward Bell, Senior Director, Global Technical Alliances & Solutions, Striim Matthew Burrows, Director, Databases Migration and Modernizations, Microsoft For organizations modernizing mission-critical applications, moving Oracle workloads to Microsoft Azure is a pivotal step toward realizing the benefits of a fully managed, cloud-native data architecture. Azure Database for PostgreSQL offers built-in high availability, elastic scale, enterprise security, and integration across Azure’s analytics and AI ecosystem—all without the operational overhead of managing legacy infrastructure. The challenge many teams face is how to migrate years of operational data from Oracle into Azure Database for PostgreSQL without introducing downtime, risk, or data drift. Microsoft and Striim solve this challenge together. Striim’s log-based Change Data Capture (CDC) continuously streams every Oracle transaction into Azure Database for PostgreSQL in real time to deliver zero-data-loss migration, continuous validation, and minimal impact on live applications. As part of the Microsoft Unlimited Database Migration Program, Striim is optimized to help organizations accelerate and de-risk their journey to Azure by combining enterprise-grade CDC technology, architectural best practices, and hands-on partner expertise. This joint solution empowers enterprises to modernize on 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 Database for PostgreSQL migrations using Striim. Why Use Striim for Continuous 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 heterogeneous, mission-critical workloads across relational and non-relational systems. Real-time, AI-ready data pipelines, preparing workloads for analytics and ML once migrated. 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: Source: an existing Oracle instance (on-premises or hosted in another environment). Processing Layer: Striim, deployed in Azure for low-latency, secure data movement. Target: Azure Database for PostgreSQL (Flexible Server) Connectivity is established over standard Oracle (1521) and PostgreSQL (5432) ports, but can also utilize ports configured by the customers. Azure customers can use Private Link, VNets, and other native Azure networking controls to secure traffic throughout the 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 Database for PostgreSQL On the target side, you must provision Azure Database for PostgreSQL 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 Database for PostgreSQL corresponding to those in the Oracle source. This can be done with: 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 DB for PostgreSQL user for Striim with write privileges on the target tables. For example: 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 Database for PostgreSQL. Step 3: Building the migration pipeline A complete Oracle to Azure Database for PostgreSQL migration typically includes three coordinated stages: Schema Migration – Create equivalent tables and objects in Azure Database for PostgreSQL. Initial Load – Bulk-load historical data from Oracle into Azure. 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 Database for PostgreSQL. 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 PostgreSQL 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 PostgreSQLInitialLoadWriter USING DatabaseWriter ( Username:'striim_user', Password:'strongpassword', ConnectionURL:'jdbc:PostgreSQL://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 Database for PostgreSQL. A CDC example in TQL 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 PostgreSQLCDCWriter USING DatabaseWriter ( Username:'striim_user', Password:'strongpassword', ConnectionURL:'jdbc:PostgreSQL://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 Database for PostgreSQL environment is fully synchronized, and you are ready to move applications off Oracle: Pause writes to Oracle. Temporarily stop application writes to the source. Validate record counts. Compare row counts (and optionally checksums or spot checks) between Oracle and Azure Database for PostgreSQL. Striim has recently released a new tool called Validata to automatically do this. Please reach out to learn more. Redirect application traffic to Azure Database for PostgreSQL. Update connection strings so applications now point at the Azure PostgreSQL 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 PostgreSQL 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 PostgreSQL Database, ensures every transaction lands with integrity. Start your modernization journey today by connecting with Striim directly through your Microsoft representative.
