Azure Managed Instance Migration Checklist: Oracle DBA's Step-by-Step Guide 2026

Azure Managed Instance Migration Checklist for Oracle DBAs

Your Complete Pre-Migration, Migration, and Post-Migration Validation Guide

📅 February 02, 2026

👤 Chetan Yadav - Senior Oracle & Cloud DBA

⏱️ 16-18 min read

⏱️ Estimated Reading Time: 16–18 minutes

☁️ Azure Managed Instance Migration - Enterprise-Grade Oracle to Cloud Migration

Two weeks before our planned Azure migration cutover, the project manager asked me, "We've tested the migration three times in dev. What could possibly go wrong in production?"

I showed him my checklist. Sixty-three items. He thought I was being overcautious. Until we hit production and discovered our application connection strings were hardcoded with Oracle-specific syntax that Azure SQL Managed Instance didn't support. The migration succeeded, but the application couldn't connect.

That's when he understood: migration isn't just moving data. It's validating every assumption about how your application interacts with the database.

This checklist represents lessons from five Azure Managed Instance migrations, including two that required emergency rollbacks. If you're an Oracle DBA planning an Azure migration, this is the checklist I wish I had on my first project.

📚 Table of Contents

1. Pre-Migration Assessment: What You Must Know Before Starting
2. Azure Managed Instance Sizing and Configuration
3. Database Schema Compatibility Analysis
4. Application Connection String Validation
5. Migration Execution Checklist
6. Post-Migration Validation Steps
7. Rollback Planning and Testing
8. Performance Baseline Comparison
9. FAQ
10. Related Reading from Real Production Systems

1. Pre-Migration Assessment: What You Must Know Before Starting

The biggest migration failures happen before the migration even starts. They happen when teams skip proper assessment and discover fundamental incompatibilities after they've already committed to the migration timeline.

Current Oracle Database Inventory

Before touching Azure, document what you currently have:

Assessment Item	What to Check	Why It Matters
Oracle Version	SELECT * FROM v$version	Determines compatibility path to Azure SQL
Database Size	SUM of data files + temp + logs	Affects migration method and Azure instance sizing
Active Connections	Peak concurrent sessions	Azure Managed Instance has connection limits per tier
Transaction Volume	Transactions per second	Determines required Azure compute tier

Critical Oracle Features Check

Azure SQL Managed Instance does NOT support these Oracle features. If you use them, you need migration strategies:

• ❌ Oracle packages - No direct equivalent, must rewrite as stored procedures
• ❌ Database links (DBLink) - Use linked servers or elastic queries instead
• ❌ Materialized views - Convert to indexed views or scheduled refresh
• ❌ Oracle-specific datatypes - RAW, LONG, BFILE need conversion
• ❌ Autonomous transactions - No direct support in Azure SQL

SQL - Identify Oracle-Specific Features

SELECT object_type, COUNT(*) as object_count FROM dba_objects WHERE object_type IN ( 'PACKAGE', 'PACKAGE BODY', 'MATERIALIZED VIEW', 'DATABASE LINK' ) AND owner NOT IN ('SYS', 'SYSTEM', 'OUTLN') GROUP BY object_type ORDER BY object_count DESC;

What you do with this output: Each non-zero count represents a migration challenge. Zero packages? Easy. 200 packages? Plan significant refactoring work.

2. Azure Managed Instance Sizing and Configuration

The most common sizing mistake is choosing Azure instance tiers based on Oracle database size. That's wrong. Size based on workload characteristics, not data volume.

Azure Managed Instance Tiers

Tier	Best For	vCores	Storage
General Purpose	Most Oracle workloads	4-80 vCores	Up to 16TB
Business Critical	High IOPS, low latency	4-80 vCores	Up to 4TB

Sizing Decision Tree

Choose General Purpose if:

• ✅ IOPS requirements under 5,000
• ✅ Acceptable latency is 5-10ms
• ✅ Cost optimization is priority
• ✅ Read replicas not required immediately

Choose Business Critical if:

• ✅ IOPS requirements exceed 10,000
• ✅ Latency must be under 2ms
• ✅ Built-in read replicas needed
• ✅ HA/DR is critical

Configuration Checklist

PowerShell - Create Azure Managed Instance

New-AzSqlInstance ` -Name "prod-oracle-migration" ` -ResourceGroupName "rg-production-dbs" ` -Location "East US" ` -SubnetId "/subscriptions/.../subnets/mi-subnet" ` -VCore 16 ` -StorageSizeInGB 2048 ` -Edition "GeneralPurpose" ` -ComputeGeneration "Gen5" ` -LicenseType "BasePrice"

License considerations: If you have Oracle licenses with Software Assurance, use LicenseType "BasePrice" for Azure Hybrid Benefit savings (up to 55% cost reduction).

3. Database Schema Compatibility Analysis

Schema conversion is where most migrations hit unexpected delays. Oracle and Azure SQL use fundamentally different approaches to identical concepts.

Datatype Mapping

Oracle Type	Azure SQL Type	Notes
VARCHAR2	VARCHAR / NVARCHAR	Max 4000 → 8000 chars
NUMBER	DECIMAL / NUMERIC	Precision mapping required
DATE	DATETIME2	Different precision
CLOB	VARCHAR(MAX)	No LOB locators
BLOB	VARBINARY(MAX)	Storage differences

Schema Conversion Script

SQL - Generate Azure-Compatible Schema

-- Oracle: Generate CREATE TABLE statements SELECT 'CREATE TABLE ' || table_name || ' (' || CHR(10) || LISTAGG( ' ' || column_name || ' ' || CASE data_type WHEN 'VARCHAR2' THEN 'VARCHAR(' || data_length || ')' WHEN 'NUMBER' THEN 'DECIMAL(' || data_precision || ',' || data_scale || ')' WHEN 'DATE' THEN 'DATETIME2' WHEN 'CLOB' THEN 'VARCHAR(MAX)' ELSE data_type END || CASE nullable WHEN 'N' THEN ' NOT NULL' ELSE '' END, ',' || CHR(10) ) WITHIN GROUP (ORDER BY column_id) || CHR(10) || ');' FROM user_tab_columns WHERE table_name = 'YOUR_TABLE_NAME' GROUP BY table_name;

What this does: Converts Oracle DDL to Azure SQL compatible syntax. Review manually before execution - automated conversion catches 80% of issues, the other 20% require human judgment.

4. Application Connection String Validation

This is the step that catches teams off guard. Your application connects to Oracle using TNS or JDBC. Azure SQL Managed Instance uses completely different connection syntax.

Connection String Changes

Oracle TNS (Old):

Oracle TNS Connection

PROD_DB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = oracle-prod.company.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = PROD) ) )

Azure SQL Managed Instance (New):

Azure SQL Managed Instance Connection

Server=prod-oracle-migration.database.windows.net; Database=PROD; User Id=sqladmin; Password=YourStrongPassword; Encrypt=True; TrustServerCertificate=False; Connection Timeout=30;

Application Code Changes Required

Beyond connection strings, these code patterns break when moving from Oracle to Azure SQL:

• ❌ Oracle sequences - Replace with IDENTITY columns or SEQUENCE objects
• ❌ Dual table queries - Remove "FROM DUAL", not needed in Azure SQL
• ❌ ROWNUM - Replace with OFFSET/FETCH or ROW_NUMBER()
• ❌ (+) outer join syntax - Rewrite using ANSI JOIN syntax
• ❌ NVL function - Replace with ISNULL or COALESCE

5. Migration Execution Checklist

This is the actual migration day checklist. Print it. Check off each item as you complete it. Skipping steps causes production failures.

Pre-Migration (T-4 Hours)

1. ✅ Notify all stakeholders of migration window start time
2. ✅ Disable all automated jobs in Oracle database
3. ✅ Take final full backup of Oracle database
4. ✅ Verify backup completes successfully
5. ✅ Document current connection count (baseline for validation)
6. ✅ Capture Oracle AWR report for last 24 hours

Migration Execution (T-0)

1. ✅ Put Oracle database in read-only mode
2. ✅ Verify no active transactions remain
3. ✅ Start Azure Database Migration Service (DMS)
4. ✅ Monitor DMS progress (log into Azure Portal)
5. ✅ Document any migration warnings or errors

Initial Data Validation (T+1 Hour)

1. ✅ Verify row counts match between Oracle and Azure
2. ✅ Check for failed object migrations
3. ✅ Validate primary keys and indexes exist
4. ✅ Test database connectivity from application server
5. ✅ Run data validation queries (checksums, min/max values)

SQL - Row Count Validation

-- Run on Oracle SELECT table_name, COUNT(*) as row_count FROM user_tables WHERE table_name IN ('CUSTOMERS', 'ORDERS', 'PRODUCTS') GROUP BY table_name ORDER BY table_name; -- Run on Azure SQL (compare results) SELECT t.name AS table_name, SUM(p.rows) AS row_count FROM sys.tables t INNER JOIN sys.partitions p ON t.object_id = p.object_id WHERE p.index_id IN (0,1) AND t.name IN ('CUSTOMERS', 'ORDERS', 'PRODUCTS') GROUP BY t.name ORDER BY t.name;

6. Post-Migration Validation Steps

Migration success is not "data moved." Migration success is "application functions identically to before with acceptable performance."

Functional Validation

Test Category	What to Test	Pass Criteria
Data Integrity	Row counts, checksums, key values	100% match with Oracle
Application Login	Users can authenticate	All test users successful
CRUD Operations	Create, Read, Update, Delete	All functions work
Reporting	Reports generate correctly	Output matches Oracle baseline
Batch Jobs	Scheduled processes run	Complete within SLA

Performance Validation

Performance in Azure will NOT match Oracle exactly. Azure SQL Managed Instance uses different execution plans, different caching, different I/O patterns. Expect variance, but within acceptable bounds.

• ✅ Compare key transaction response times (should be within 20% of Oracle baseline)
• ✅ Verify no query timeout errors
• ✅ Check for blocking or deadlocks
• ✅ Monitor Azure SQL DTU/vCore utilization
• ✅ Review slow query log for optimization candidates

7. Rollback Planning and Testing

Every migration plan must include rollback procedures. The question is not "will we need to roll back?" but "how quickly can we roll back if we need to?"

Rollback Decision Criteria

Immediate rollback if:

• ❌ Application cannot connect to Azure SQL Managed Instance
• ❌ Critical business function is broken
• ❌ Data integrity issues discovered (row counts don't match)
• ❌ Performance degradation exceeds 50% of baseline

Rollback procedure:

1. Announce rollback to all stakeholders
2. Put Azure SQL in read-only mode (prevent new data)
3. Restore Oracle database from backup
4. Revert application connection strings to Oracle
5. Verify Oracle database is accepting connections
6. Document what went wrong for post-mortem

8. Performance Baseline Comparison

You cannot optimize what you don't measure. Before migration, establish Oracle performance baselines. After migration, compare Azure performance to these baselines.

Key Metrics to Baseline

Metric	Oracle Baseline	Azure Target
Average Query Time	Document from AWR	Within 20% of Oracle
Transactions/Second	Peak and average	Match or exceed Oracle
CPU Utilization	Average and peak	Under 80% sustained
IO Latency	Read and write ms	Under 10ms (General Purpose)

SQL - Azure SQL Performance Metrics

-- Azure SQL: Monitor query performance SELECT TOP 20 qs.total_elapsed_time / qs.execution_count / 1000 AS avg_elapsed_time_ms, qs.execution_count, SUBSTRING(qt.text, (qs.statement_start_offset/2)+1, ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(qt.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) AS query_text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt ORDER BY avg_elapsed_time_ms DESC;

9. FAQ

How long does a typical Oracle to Azure SQL Managed Instance migration take?

For a 500GB Oracle database with moderate complexity, expect 12-16 hours for migration execution. But the real timeline is pre-migration work (schema conversion, application testing) which typically takes 4-8 weeks. Don't underestimate assessment and preparation time. A rushed migration is a failed migration.

Can I migrate Oracle packages directly to Azure SQL Managed Instance?

No. Oracle packages have no direct equivalent in Azure SQL. You must refactor packages into individual stored procedures, functions, and views. This is one of the most time-consuming aspects of Oracle to Azure migration. Budget significant development time for package conversion and testing.

What happens to Oracle RAC in Azure migration?

Oracle RAC (Real Application Clusters) translates to Azure SQL Managed Instance high availability architecture. In Business Critical tier, you get built-in read replicas and automatic failover. In General Purpose tier, you get zone redundancy but not read replicas. Evaluate your HA requirements carefully when choosing Azure tiers.

Should I mention Azure migration experience on my resume if I've only done test migrations?

Be honest. Write "Hands-on experience with Oracle to Azure SQL Managed Instance migration in test environments including schema conversion, data migration, and application testing." Employers value migration knowledge even if it's not production experience yet. The skills transfer directly to production migrations.

10. Related Reading from Real Production Systems

If you want to deepen your understanding of cloud database migrations and Oracle in cloud environments, the following articles from real production experience may also be useful:

• N8N Oracle Telegram Alerts: Automating Database Monitoring Why it matters: After migrating to Azure, you'll need monitoring automation. This guide shows how to set up alerts for Azure SQL Managed Instance using N8N and Telegram for real-time notification of migration issues or performance problems.
• Oracle Database 23ai: Revolutionizing Data Distribution Across the Globe Why it matters: Understanding modern Oracle architecture helps you appreciate why Azure SQL Managed Instance takes different approaches to similar problems. This article provides context on what you're migrating from.
• SAP HANA Logging Behavior Explained: A Production DBA's Guide Why it matters: Migration troubleshooting methodology applies across database platforms. The diagnostic approach in this article helps when investigating Azure SQL Managed Instance post-migration issues.
• AWS RDS Parameter Groups: The Oracle DBA's Complete Guide to Cloud Database Tuning Why it matters: While focused on AWS, the principles of cloud database parameter management apply to Azure as well. Understanding what you can and cannot tune in managed database services is critical for successful migrations.
• Cloud Migration Cost Analysis: Oracle to Azure SQL Managed Instance TCO Why it matters: Migration decisions should be driven by total cost of ownership analysis. This article breaks down the true costs of running Oracle in Azure including licensing, compute, storage, and operational overhead.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 14+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments. He specializes in high availability architecture, performance tuning, disaster recovery, and cloud migrations.

Throughout his career, Chetan has supported mission-critical databases for enterprises in finance, healthcare, and e-commerce sectors. He has led multiple successful cloud migration projects, including Oracle to Azure SQL Managed Instance, Oracle to AWS RDS, and PostgreSQL to Azure Database migrations.

Chetan is passionate about mentoring early-career DBAs and sharing real-world production lessons that aren't found in documentation. His writing focuses on practical decision-making, career growth, and the operational realities of database administration in modern cloud-first organizations.

This blog focuses on real-world DBA problems, career growth, and practical learning — not theoretical documentation or vendor marketing.

🔗 LinkedIn 🎥 YouTube 📸 Instagram 🐦 Twitter (X) 📘 Facebook 📬 Newsletter