Verdict: There's no automatic conversion for Oracle AQ. Choose based on where the database is going:

• If Oracle stays: keep AQ as-is on Oracle Database@Azure or Oracle on Azure VMs. This is the lowest-risk option.
• If you're leaving Oracle: move to Azure Service Bus (Premium if you need JMS). Use a transactional outbox to keep the atomic "database write + enqueue" behaviour that AQ gives you.

Option 1: Keep Oracle and move it as-is (recommended when AQ is heavily used)

• AQ and Transactional Event Queues (TxEventQ) are database features. They work unchanged on Oracle Database@Azure (Exadata or Autonomous) or on Oracle running on Azure VMs.
• Your queue tables, propagation, PL/SQL DBMS_AQ callers, JMS clients and the atomic enqueue in the same transaction as your data changes all keep working.
• Migrate with Data Guard, RMAN or Zero Downtime Migration. Queue tables go with the database.
• Microsoft guidance: https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/oracle-on-azure/

Option 2: Rebuild on Azure services (when moving to PostgreSQL, Azure SQL or cloud-native apps)

Things that will catch you out

1. You lose transactional atomicity. With AQ, the enqueue commits in the same transaction as your data changes. Service Bus and Event Hubs can't join a database transaction (no XA or distributed transactions). Fix this with the transactional outbox pattern: write events to an outbox table in the same transaction, then relay them with a worker, CDC or Debezium. Pattern: https://learn.microsoft.com/azure/architecture/databases/guide/transactional-outbox-cosmos
2. The migration tools skip AQ. SSMA for Oracle and ora2pg don't convert DBMS_AQ, DBMS_AQADM, queue tables or propagation. Take an inventory with DBA_QUEUES, DBA_QUEUE_SUBSCRIBERS and DBA_QUEUE_SCHEDULES, and search your code for DBMS_AQ calls.
3. Delivery semantics differ. Service Bus gives at-least-once delivery, so make consumers idempotent and turn on duplicate detection. Map AQ's retry count and retry delay to Service Bus max delivery count plus dead-lettering.
4. Size and throughput limits. Service Bus Standard caps messages at 256 KB; Premium allows up to 100 MB. Large AQ payloads (big RAW, BLOB or ADT messages) may need the claim-check pattern, which stores the payload in Blob Storage and sends only a reference.
5. Payload types. Oracle object-type (ADT) payloads have to be turned into JSON or Avro, and the schema contract has to be agreed with every consumer.

Suggested sequence: inventory your queues and code. Lift and shift to Oracle Database@Azure or Azure VMs first if you're short on time. Then rebuild on Service Bus with the outbox pattern, running both side by side during the switchover, with a bridge that relays messages between AQ and Service Bus.

Oracle AQ and TxEventQ reference: https://docs.oracle.com/en/database/oracle/oracle-database/23/adque/

Recommendation: If the target is a managed Azure database such as Azure SQL Database, move AQ messaging to Azure Service Bus. Keep transactional consistency with an outbox table, and rewrite PL/SQL consumers as Azure Functions or application services [1][6][8].

Key facts from the passages:

• Why it's hard: AQ enqueues and dequeues inside ordinary database transactions, so a business update and its message commit or roll back together. External brokers don't do this [1]. Service Bus is the closest Azure equivalent, but it runs outside the database, so its enqueue and dequeue aren't part of a database transaction [6].
• No in-database target on Azure SQL Database: It has no Service Broker and no other in-database queue. The mapping is rated low ("L") with no direct equivalent [8].
• Steps [8]:
  1. Recreate the queue definitions in Service Bus.
  2. Write to an outbox table in the same transaction as the business DML. A function or worker then relays those rows to Service Bus.
  3. Replace dequeue-driven PL/SQL with code triggered by Service Bus. Azure Functions has native Service Bus triggers [3].
• How AQ features map to Service Bus [6]:
  • Point-to-point queues → Service Bus queues.
  • Publish-subscribe with rule-based subscribers → topics with filtered subscriptions.
  • JMS → full JMS 2.0 on the Premium tier; Standard supports only the JMS 1.1 queue subset.
  • Storage queues are the simpler alternative [1][8].
• Assessment gap: Queue tables, subscriber rules and propagation schedules are configuration that assessment tools rarely surface. You need to inventory them by hand [1].
• AQ itself is still supported: Oracle's 19c Upgrade Guide says AQ is not deprecated. 21c deprecates sharded queues in favour of Transactional Event Queues, which are the next version of the same feature [1]. Don't confuse AQ with Streams, which was desupported in 19c. Streams used AQ queues internally, and a Streams feed needs its own replacement pipeline, such as GoldenGate or Azure Data Factory [5].

What the passages don't answer: They don't give a recommendation for keeping AQ as-is on Oracle on an Azure VM. Passage [7] says any Oracle release can be installed on a VM, but it doesn't mention AQ, so I can't cite the passages for "lift AQ unchanged onto a VM." The VM migration guide covers data movement only (RMAN, Data Pump, Data Guard, GoldenGate) [2].

Sources:

• [2] https://learn.microsoft.com/en-us/azure/virtual-machines/workloads/oracle/oracle-migration
• [4] https://docs.oracle.com/en/database/oracle/oracle-database/19/adque/aq-introduction.html
• [1], [3], [5], [6], [7], [8] are internal reference entries with no URLs.

Verdict

For Oracle Advanced Queuing (AQ), the dataset's recommended path is: rehost on Oracle Database@Azure to keep AQ unchanged, or if moving off Oracle engine entirely, redesign onto Azure Service Bus (partial fidelity, effort L) — not Azure SQL Database (no equivalent) and only partially onto Azure SQL Managed Instance (Service Broker).

Scoped facts

Applies to: Oracle AQ, introduced pre‑11.2, no deprecation/desupport recorded, across all versions 11.2–26ai. [Oracle Advanced Queuing (AQ)](oracleFeature dataset entry — no source URL recorded on the feature doc itself)

If staying on Oracle Database@Azure: AQ "stays as it is" — no redesign needed. — [Replace Oracle Advanced Queuing with Azure Service Bus](pattern doc, no URL field populated for this pattern's own note; see mapping sources below)

Target: Azure Service Bus — fidelity: partial, effort: L

• Rationale: Service Bus provides the same broker vocabulary as AQ — point-to-point queues, pub/sub via topics+subscriptions, rule-based routing via subscription filters, peek-lock/receive-and-delete for dequeue modes, scheduled delivery for delay, TTL + dead-letter subqueue for expiration/exceptions, sessions for FIFO/correlation. Introduction to Azure Service Bus messaging, Azure Functions overview
• Major caveat: Service Bus transactions only group operations against a single messaging entity and cannot include database DML — the Oracle pattern of enqueueing inside the same transaction as table DML must move to a transactional outbox table + relay (Azure Function, SQL Agent job, pg_cron, or change-feed reader), with idempotent consumers. Introduction to Azure Service Bus messaging
• Migration steps recorded: inventory queues/subscribers/transformations via DBA_QUEUES/DBA_QUEUE_SUBSCRIBERS → create Service Bus queues (single-consumer) or topics+subscriptions (multi-consumer) → replace PL/SQL enqueue with outbox-table+relay → replace dequeue loops/notifications with triggered Functions or SDK receivers → map priority/expiration/retry to scheduled enqueue/TTL/max delivery count.
• Tier note: Premium tier is fully JMS 2.0 compliant and zone-redundant; Standard supports only the JMS 1.1 queue subset. Introduction to Azure Service Bus messaging

Target: Azure SQL Managed Instance — fidelity: partial, effort: L

• Service Broker is the nearest in-engine equivalent for PL/SQL code that enqueues/dequeues inside a transaction, and is available on Managed Instance. T-SQL differences between SQL Server and Azure SQL Managed Instance
• Major caveat: routing is restricted to LOCAL or another managed instance by DNS name on port 4022; CREATE REMOTE SERVICE BINDING (dialog security) is not supported; broker is on by default and cannot be toggled with ENABLE_BROKER/DISABLE_BROKER. Applies to General Purpose, Next-gen General Purpose, and Business Critical tiers. T-SQL differences between SQL Server and Azure SQL Managed Instance

Target: Azure SQL Database — fidelity: none, effort: L

• Blocker caveat: Service Broker is not available in Azure SQL Database at all (only in Managed Instance, and even there routing is limited to other managed instances). Messaging must move to Service Bus/Storage queues + outbox table instead. Compare SQL Database Engine features: Azure SQL Database vs Azure SQL Managed Instance

When not to use Service Bus: if the queue is purely an intra-database worklist consumed by code in the same database, a table-as-queue pattern (SQL Server READPAST/UPDLOCK, PostgreSQL SKIP LOCKED) is simpler and preserves single-transaction semantics; on Managed Instance, Service Broker is also an in-engine option. High-volume telemetry/event streaming belongs in Azure Event Hubs, not Service Bus. — Replace Oracle Advanced Queuing with Azure Service Bus pattern.

Gaps / disputes

• No dispute documents were found touching AQ mappings or caveats.
• The dataset lists no explicit mapping for AQ onto "Oracle on Azure VM" or "Oracle Database@Azure" as a mapping record with its own fidelity/sources — the "stays as it is" claim comes only from the pattern's whenNotTo note, not from a dedicated mapping/caveat/source citation. Treat that specific claim as lower-confidence pending a sourced mapping entry.

Verdict

For Oracle Advanced Queuing (AQ), the recommended path is: stay on AQ if you're on Oracle Database@Azure, or redesign to Azure Service Bus (queues/topics) with a transactional outbox pattern if you're moving to Azure SQL Database or PostgreSQL. On Azure SQL Managed Instance, Service Broker is a partial in-engine alternative but requires a rewrite, not a lift-and-shift.

Scoped facts

Feature scope: Oracle Advanced Queuing (AQ), introduced pre-11.2, applies across 11.2–26ai (no deprecation/desupport recorded) — Introduction to Oracle Database Advanced Queuing (AQ User's Guide 19c).

1. Oracle Database@Azure — AQ stays as-is; no migration needed, since it's the same Oracle engine — Replace Oracle Advanced Queuing with Azure Service Bus (KB pattern).

2. Azure SQL Database — Fidelity: none, Effort: L (applies to Oracle 11.2 through 26ai). Azure SQL Database has no Service Broker or other in-database queue, so AQ has no direct target; messaging must move to Service Bus (or Storage queues) with an outbox table for transactional consistency — Compare SQL Database Engine features: Azure SQL Database vs Azure SQL Managed Instance, Introduction to Azure Service Bus messaging.

• Blocker caveat: Service Broker is not available in Azure SQL Database at all — Compare SQL Database Engine features.

3. Azure SQL Managed Instance — Fidelity: partial, Effort: L (11.2–26ai). Service Broker is the nearest in-engine, transactional queuing equivalent, but code is rewritten rather than translated because Service Broker's conversation model differs from AQ's queue tables — T-SQL differences between SQL Server and Azure SQL Managed Instance.

• Major caveat (General Purpose, Next-gen General Purpose, Business Critical tiers): Service Broker routes may target only LOCAL or another managed instance's DNS name on port 4022; dialog security (CREATE REMOTE SERVICE BINDING) is unsupported; the broker cannot be toggled per-database — T-SQL differences.

4. Azure Service Bus — Fidelity: partial, Effort: L (11.2–26ai). Service Bus supports the patterns AQ apps use — point-to-point queues, pub-sub topics with filtered subscriptions, FIFO via sessions, dead-lettering, delayed delivery, expiration (TTL) — Introduction to Azure Service Bus messaging, Azure Functions overview.

• Major caveat: Service Bus transactions only span a single messaging entity and cannot include database DML — the Oracle pattern of enqueueing inside the same transaction as table DML requires an outbox table or idempotent consumers — Introduction to Azure Service Bus messaging.

How-to detail (pattern guidance)

Per Replace Oracle Advanced Queuing with Azure Service Bus (Dataset):

• Concept mapping: point-to-point queue → Queue; multi-consumer/pub-sub → Topic + filtered subscriptions; browse/lock/remove dequeue modes → Peek / Peek-lock / Receive-and-delete; delivery delay → Scheduled delivery; expiration → TTL; exception queue → dead-letter subqueue; correlation ID/dequeue conditions → Sessions; PL/SQL callback → Azure Function with a Service Bus trigger.
• Transaction redesign: use the transactional outbox pattern — write business row + outbox row in one DB transaction, a relay (Azure Function timer, SQL Agent job on MI, pg_cron, or change-feed reader) publishes to Service Bus and marks rows sent; consumers must be idempotent since the relay may publish twice.
• Retention: AQ messages persist indefinitely in queue tables; Service Bus messages are bound by TTL, so long-lived queue contents belong in a target database table, not the broker.
• Inventory before migration: catalogue queue tables/payload types, subscribers and rules, retention settings, and every dequeue condition — each becomes a filter, session key, or app code on the target.
• When Service Bus is NOT the right target: an intra-database work list consumed only by code in the same database — use table-as-queue (READPAST/UPDLOCK on SQL, SKIP LOCKED on PostgreSQL), or Service Broker on Managed Instance; for high-volume telemetry/event streaming, use Azure Event Hubs instead.

Gaps / disputes

No disputes in the dataset touch Oracle Advanced Queuing migration. No mapping exists for AQ against Oracle on Azure VMs or Oracle Database@Azure as a target row — the only stated guidance for Oracle Database@Azure is that AQ requires no migration at all (same engine).