No, not as-is. T-SQL on Azure SQL Managed Instance has no PRAGMA AUTONOMOUS_TRANSACTION or any equivalent. A nested BEGIN TRAN only increments @@TRANCOUNT, and an outer ROLLBACK undoes everything, including the "inner" commit. You can get the same behaviour through workarounds, and which one fits depends on what the autonomous block was doing.

Why it doesn't carry over

• SQL Server nested transactions aren't real: an inner COMMIT only decrements @@TRANCOUNT, and the outermost ROLLBACK undoes all of it. Savepoints (SAVE TRAN) let you roll back part of a transaction, but they can't make part of it survive when the outer one rolls back. https://learn.microsoft.com/sql/t-sql/language-elements/commit-transaction-transact-sql
• SSMA for Oracle flags autonomous transactions as needing attention. On on-prem SQL Server it has emulated them with helper extended procedures, but extended procs don't run on MI, so plan to rewrite these by hand. https://learn.microsoft.com/sql/ssma/oracle/sql-server-migration-assistant-for-oracle-oracletosql

Workarounds, most common first

1. Table-variable capture (best for error or audit logging, which is about 80% of autonomous-transaction use). Table variables aren't affected by a rollback. Write log rows into a @log table variable, ROLLBACK in the CATCH block, then INSERT from @log into the real log table. It's simple, fast and needs no extra infrastructure. The limit is that the rows only persist if your code reaches the post-rollback insert.
2. Loopback linked server. Create a linked server that points at the MI itself and set remote proc transaction promotion = false. Calls through it (EXEC LOOPBACK.db.dbo.usp_log ...) then run and commit in their own session, which is the closest match to real autonomous semantics. MI supports linked servers. The costs:
   • each call opens a separate connection, which adds overhead;
   • you need to manage the credentials for the loopback login;
   • it can self-deadlock if the called code touches rows the caller has locked. Oracle has the same risk with autonomous transactions. https://learn.microsoft.com/sql/relational-databases/system-stored-procedures/sp-serveroption-transact-sql
3. Service Broker. Send a message and let an activation procedure do the write. This works because Service Broker is supported within a single MI. It's asynchronous and decoupled, which suits audit trails, but the message send itself is transactional. So either send outside the outer transaction, or accept that a rollback also removes the message.
4. Move it to the app tier. Have the application write the log or sequence row on its own connection. This is often the cleanest option long term.

Migration checklist

• Inventory: SELECT owner, name, type FROM dba_source WHERE UPPER(text) LIKE '%AUTONOMOUS_TRANSACTION%';
• Sort each hit by what it does: logging (use option 1), a custom sequence or ID generator (replace with a SEQUENCE object, since sequence values aren't rolled back), a commit inside a trigger (redesign it), or something else (option 2 or 4).
• Retest error paths specifically. That's where the behaviour will differ quietly.

No, not as-is. Azure SQL Managed Instance has no autonomous transactions, and the emulation SSMA generates for them won't deploy there. Plan to rewrite every one of these routines by hand.

Key facts

• No native equivalent. SQL Server has no autonomous transactions. A nested BEGIN TRAN joins the outer transaction, so its work rolls back with the caller. [1][5]
• SSMA's report is misleading.
  • For anonymous blocks, SSMA doesn't convert the pragma at all and raises error O2SS0205. [3][4]
  • For procedures and functions, SSMA reports the pragma as "converted". It splits each routine into an implementation procedure plus a wrapper. The wrapper calls the extended stored procedure master..xp_ora2ms_exec2_ex, which opens a second loopback connection. Microsoft documents this as slow compared with Oracle. [3][4]
  • Managed Instance doesn't support extended stored procedures, so this converted code can't be deployed there. The same applies to Azure SQL Database. [1][2]
  • Source: https://learn.microsoft.com/en-us/sql/ssma/oracle/messages/o2ss0205
• Why it matters: these routines usually handle error logging, audit trails or counters that must survive a rollback of the main work. Any replacement changes the behaviour, so each routine needs its own design decision. [5]

What to do instead [1][2]

1. List every routine that uses PRAGMA AUTONOMOUS_TRANSACTION. Sort them into audit logging, error logging, counters and business logic.
2. Logging and audit:
   • Write the log rows to a table variable, which keeps its data after a rollback. Save them to a real table once the outer transaction ends.
   • Or send the log to Azure Monitor or Event Hubs.
   • Or write the audit rows through a separate connection from the application.
3. Business logic: restructure it so the independent work is a separate call from the application. On Managed Instance, another option is to move the side effect into a Service Broker activation procedure.
4. Check before you deploy: search the converted T-SQL for xp_ora2ms_exec2_ex. Every hit is a routine you still need to rewrite.

Verdict: No — PRAGMA AUTONOMOUS_TRANSACTION has no working equivalent on Azure SQL Managed Instance. The mapping is rated workaround fidelity with L (large) effort, and the standard emulation mechanism is explicitly blocked on Managed Instance.

Scoped facts (Oracle 11.2–23ai → Azure SQL Managed Instance, all tiers: General Purpose, Next-gen General Purpose, Business Critical)

• SQL Server (and therefore Azure SQL MI) has no autonomous transaction concept: nested BEGIN TRAN calls simply join the outer transaction. — SSMA for Oracle: O2SS0205 Unable to convert PRAGMA AUTONOMOUS_TRANSACTION
• Microsoft's SQL Server Migration Assistant (SSMA) tries to emulate the pragma at the routine level by splitting the routine into an implementation procedure plus a wrapper that calls an extended stored procedure (xp_ora2ms_exec2_ex in master) to open a second connection and run the logic independently. This is documented as slow compared with native Oracle behavior. — SSMA for Oracle: O2SS0205
• Blocker caveat: Azure SQL Managed Instance does not support extended stored procedures at all (sp_addextendedproc/sp_dropextendedproc are unavailable). This means SSMA's extended-procedure-based emulator cannot be installed on Managed Instance, and any converted routine that depends on it must be manually rewritten. Applies to all MI tiers (General Purpose, Next-gen General Purpose, Business Critical). — T-SQL differences between SQL Server and Azure SQL Managed Instance
• Additionally, SSMA doesn't even convert the pragma inside anonymous blocks at all (error O2SS0205), regardless of target. — SSMA for Oracle: O2SS0205
• Recommended alternative per the dataset's rationale: for logging-style autonomous transactions (the most common use case), replace with table variables (which survive rollback) or an external log sink, rather than trying to emulate the pragma. — SSMA for Oracle: Converting Oracle Schemas

Note on scope

This mapping applies to Oracle 11.2 through 23ai (the feature itself was introduced pre-11.2, per [oracleFeature: PRAGMA AUTONOMOUS_TRANSACTION], and is not marked deprecated/desupported in the dataset).

Alternative target noted in the dataset (not what you asked, but relevant)

If Azure SQL MI is not a hard requirement, the dataset also has a mapping to Azure Database for PostgreSQL Flexible Server, also rated workaround/M effort — PostgreSQL has no autonomous transactions either, but PL/pgSQL allows COMMIT/ROLLBACK in procedures called at the top of the call stack, and tools (Ora2Pg, Microsoft's PG schema-conversion tooling) emulate the pragma via a second connection (dblink or pg_background), which adds a connection per call and bypasses the caller's snapshot. — PostgreSQL documentation: Transaction management in PL/pgSQL

No disputes are recorded in the dataset for this feature.

Verdict: No — not natively, and not even via SSMA's usual emulation. PRAGMA AUTONOMOUS_TRANSACTION has no equivalent on Azure SQL Managed Instance, and the standard automated-conversion path is documented to be blocked on that specific target.

Scoped facts (Oracle 11.2–23ai, target: Azure SQL Managed Instance):

• Fidelity is workaround, effort L — "SQL Server has no autonomous transaction: nested BEGIN TRAN calls join the outer transaction." Logging-style uses are recommended to be replaced with table variables (which survive rollback) or an external log sink, rather than mechanically converted. SSMA for Oracle: O2SS0205 Unable to convert PRAGMA AUTONOMOUS_TRANSACTION, T-SQL differences between SQL Server and Azure SQL Managed Instance

• Caveat (blocker, applies to General Purpose, Next-gen General Purpose, and Business Critical tiers of Azure SQL MI): Managed Instance does not support extended stored procedures (sp_addextendedproc/sp_dropextendedproc are unavailable), so SSMA's autonomous-transaction emulator — which relies on an extended stored procedure — cannot be installed there; converted routines depending on it must be rewritten. T-SQL differences between SQL Server and Azure SQL Managed Instance

• Caveat (major, Oracle 11.2–23ai): SSMA doesn't even convert the pragma inside anonymous blocks at all (error O2SS0205). For procedures/functions it emulates the pragma via extended stored procedure xp_ora2ms_exec2_ex, opening a second connection to run a split-out implementation procedure — documented by Microsoft as slow compared with Oracle, and this is exactly the mechanism blocked on Managed Instance per the caveat above. SSMA for Oracle: O2SS0205

Recorded dispute: "Does SSMA's autonomous-transaction emulation run on Managed Instance?" — SSMA reports PRAGMA AUTONOMOUS_TRANSACTION in procedures/functions as successfully converted (via the extended-proc emulation), while Microsoft's own T-SQL differences documentation states Azure SQL Managed Instance doesn't support extended stored procedures at all — i.e., one Microsoft tool marks as done what another Microsoft platform cannot host. Resolution: Treat every "converted" autonomous transaction as a manual rewrite when targeting Managed Instance (or Azure SQL Database). Typical replacements: write audit rows through a separate application-tier connection, use table variables to carry log data out of a failing transaction, or move the side effect to a Service Broker activation procedure on Managed Instance. Verify by searching converted T-SQL for xp_ora2ms_exec2_ex before deploying. SSMA for Oracle: O2SS0205 / T-SQL differences

Background: the feature itself is a core, non-deprecated part of PL/SQL (introduced pre-11.2) — Oracle's Concepts guide covers it under transactions — so this is purely a target-platform gap, not an Oracle-side deprecation. Neither Transact-SQL nor PL/pgSQL has an equivalent construct.

(Note: if PostgreSQL Flexible Server is also a candidate target, that mapping exists too — workaround via dblink/pg_background emulation with its own caveats — but you asked specifically about SQL MI, so I've scoped to that.)