Before you pick an Azure target, run the Oracle assessment you're probably skipping

Elena Perventsev — Thu, 02 Jul 2026 20:05:39 +0000

Most Oracle-to-Azure migration plans open with the wrong question: "Do we go to Azure SQL Managed Instance, PostgreSQL Flexible Server, or Oracle Database@Azure?"

You can't answer that yet. Target selection is an output of discovery, not the first slide. Until you know what's actually running in the source database, "we mostly use standard SQL" is a hope, not an assessment — and it's the kind of hope that turns into a three-week schedule slip during cut-over.

Three things determine how hard (and how expensive) the migration is. All three are discoverable before you touch Azure, and you can start today with queries against the Oracle data dictionary.

1. Feature-usage audit

Every Oracle-specific feature in active use is a potential line item of migration work, the ones with no clean Azure equivalent are where projects bleed time. Oracle already tracks this for you:

SELECT name,
       detected_usages,
       currently_used,
       last_usage_date
FROM   dba_feature_usage_statistics
WHERE  detected_usages > 0
ORDER  BY name;

Now you have an evidence-based list: partitioning, materialized views, Advanced Queuing, TDE, fine-grained auditing, spatial, and so on. Each one gets a decision — does the target support it, emulate it, or force a refactor? — instead of being discovered mid-migration.

2. Schema complexity

A rough complexity signal tells you whether this is closer to a lift-and-shift or a genuine refactor. Start with object counts by type and owner:

SELECT object_type, COUNT(*)
FROM   dba_objects
WHERE  owner = 'HRPRO'          -- your app schema
GROUP  BY object_type
ORDER  BY COUNT(*) DESC;

Then find the data types that quietly break conversion tools — the LONG, BFILE, user-defined types, and timezone-aware columns that don't map 1:1:

SELECT data_type, COUNT(*)
FROM   dba_tab_columns
WHERE  owner = 'HRPRO'
GROUP  BY data_type
ORDER  BY COUNT(*) DESC;

Heavy PL/SQL (packages, triggers, procedures) pushes you toward PostgreSQL or SQL MI refactoring effort; a thin schema with simple types opens up more targets cheaply.

3. Workload baseline

Capture the real workload now, while the source is still the source of truth. You need it twice: to size the target correctly, and to set performance gates you can actually defend when someone asks "is Azure slower?" A baseline pulled from AWR / V$ views before you migrate is worth more than any vendor sizing calculator.

Make it an artifact, not a spreadsheet

Here's the part teams skip: they run something like the above once, by hand, paste it into a slide, and move on. Six weeks later nobody can reproduce it, and the numbers are stale.

Do it as a re-runnable script that emits a structured artifact, a JSON assessment bundle you can regenerate per environment and feed into the next steps (target selection, TCO sizing, schema conversion). Repeatable discovery is what turns a migration from a narrative into a pipeline.

Full disclosure: our team wrote a book on the complete Oracle 19c → Azure path, and we've open-sourced the Chapter 1 assessment scripts under MIT so you can run this discovery step for free — whether or not the book is ever for you:

Assessment scripts (feature audit, schema complexity, workload baseline → a Migration Assessment Bundle): https://github.com/KinetiStack/oracle-to-azure-companion
The full Chapter 1 write-up (free PDF): https://kinetistackllc.com/books/oracle-to-azure/sample-chapter.pdf

If you've done an Oracle-to-Azure move: what did your assessment step fail to catch the first time? That's the stuff that bites during cut-over, I'd genuinely like to hear it in the comments.

DEV Community: Elena Perventsev

Before you pick an Azure target, run the Oracle assessment you're probably skipping

1. Feature-usage audit

2. Schema complexity

3. Workload baseline