Microsoft published an early Oracle-to-PostgreSQL migration evaluation on August 14, 2026 using the PostgreSQL extension for Visual Studio Code, Microsoft Foundry, and GitHub Copilot.

The experiment converted a Swingbench Sales Order Entry schema with PL/SQL package logic, compiled the generated objects against PostgreSQL, copied reference data, reproduced the application-facing workload, and validated business effects under concurrent calls.

The important result is not that AI makes database migration automatic. It is that assessment, conversion, compiler feedback, repairs, test generation, and findings can remain together in one reproducible VS Code workspace.

This Is an Early Evaluation

Microsoft is explicit about the experiment's boundaries.

The target was Azure HorizonDB, which is in preview and is not currently a supported target for the migration workflow. The source was Oracle Database 26ai, which had not yet been validated for the workflow.

The migration capability itself appears under Migrations (Preview) in Microsoft's PostgreSQL extension for VS Code.

Treat the walkthrough as evidence of an emerging method, not a supported production migration guarantee.

The test used:

• Oracle Database 26ai in a container

• Swingbench 2.6 with the Sales Order Entry workload

• Azure HorizonDB running PostgreSQL 17.9 as a scratch target

• PostgreSQL extension for VS Code 1.27.3

• GPT-5.2 deployed through Microsoft Foundry

• GitHub Copilot for supporting scripts and validation tooling

Versions and preview behavior will evolve. Reproduce the method against the currently supported source and target matrix before using it for planning.

Why Schema Compilation Is Not Migration Completion

A generated table or function that compiles can still behave differently from its Oracle source.

A credible validation must answer at least three questions:

• Was the required reference data copied correctly?

• Were the routines used by the application actually deployed?

• Do those routines create the same business effects under realistic calls?

The Swingbench server-side workload is useful because its business logic lives in an Oracle PL/SQL package. It includes package state, private helpers, collection types, random choices, sleeps, transaction control, and business transactions.

Those constructs expose the semantic differences that a simple table-and-index migration does not reveal.

The VS Code Workflow Acts Like a Conversion Pipeline

The migration project stores configuration, logs, source extraction, reports, generated DDL, and review artifacts under the repository's .github/postgres-migrations folder.

The workflow:

• Extracts Oracle metadata

• Builds a dependency graph

• Divides objects into dependency-aware chunks

• Applies deterministic mappings where possible

• Uses a Foundry model for contextual schema and PL/SQL conversion

• Reviews the generated PostgreSQL code

• Compiles it against the target database

• Repairs rejected SQL and retries

• Produces reports and deployment artifacts

This resembles a compiler pipeline more than a one-shot text translation.

The model can propose and revise code, but PostgreSQL provides the authoritative SQLSTATE, failing statement, type rules, and dependency behavior.

Compiler Feedback Creates a Useful Repair Loop

In the published run, analysis of the conversion log found 37 automatic correction events.

Thirty-three occurred during a second-pass review, and four followed PostgreSQL compilation failures. The workflow finished with zero failed objects and zero fallback objects in that experiment.

Corrections included:

• Guarding missing or empty current_setting values before casting

• Adjusting package-state writes so selected values survive a commit on the same connection

• Replacing invalid Oracle %TYPE references

• Repairing Oracle cursor and PostgreSQL PERFORM syntax

• Schema-qualifying table references

• Limiting a SELECT INTO that might return multiple rows

• Completing an incomplete type-creation block

• Removing unsupported DEFERRABLE clauses from check constraints

These results show the value of target-database compilation inside the loop.

They do not prove behavioral equivalence. The compiler can reject invalid syntax and types, but it cannot know whether the converted routine still implements the intended business rule.

Oracle Packages Require Architectural Translation

PostgreSQL does not provide Oracle-style packages with the same visibility, state, collection, and transaction semantics.

The experiment translated package members into schema routines with flattened names. Package records and collections became composite types, array domains, or set-returning functions. Package variables used PostgreSQL settings through set_config and current_setting.

Other translations included:

• DBMS_RANDOM.VALUE to random with range arithmetic

• DBMS_LOCK.SLEEP to pg_sleep

• DBMS_APPLICATION_INFO to application_name or custom settings

• BULK COLLECT to set-returning queries

• CONNECT BY row generation to a recursive CTE

• FORALL updates to a PL/pgSQL loop

• SYSDATE and SYSTIMESTAMP to PostgreSQL timestamp functions

• Package procedures to functions returning void

These are design choices, not mechanically equivalent syntax substitutions.

Every choice needs runtime evidence for empty collections, ordering, locking, exceptions, session pooling, state initialization, time zones, numeric casts, and performance.

The Review Report Makes Remaining Risk Visible

After successful compilation, the experiment's review report classified 34 of 78 objects as auto-approved and left 44 non-blocking behavioral divergences for application review.

Examples included:

• Oracle ENABLE NOVALIDATE constraints versus PostgreSQL validation behavior

• Reverse-key indexes becoming normal PostgreSQL btree indexes

• Package state represented through custom settings

• Mixed session-level and transaction-local state

• PostgreSQL functions being unable to commit the surrounding transaction

• ROWNUM conversions without deterministic ordering

• BULK COLLECT and FORALL behavior changing shape

• Random-number, timestamp, exception, and casting differences

The report did not hide those items because the objects compiled. It converted them into a concrete validation backlog.

That is the useful role of an AI-assisted assessment: accelerate the first prototype and expose where engineering judgment is still required.

Transaction Ownership Is a Major Migration Decision

The Oracle package in the test could issue COMMIT from inside its business logic.

PostgreSQL functions cannot commit or roll back their surrounding transaction. PostgreSQL procedures can control transactions only in specific CALL contexts, and changing functions into procedures changes the application interface.

The experiment disabled package-side commits and moved commit or rollback responsibility into the Python workload driver.

That preserved a working test path but changed transaction ownership.

Real applications must review:

• Multi-call atomicity

• Retry and idempotency behavior

• Error propagation

• Connection-pool reuse

• Package or session state

• Partial failure

• Client transaction boundaries

A successful code conversion cannot choose the correct business transaction model without application-owner involvement.

Data Movement Was Kept Separate

The migration extension converted schema and code but did not copy the Swingbench data in this test.

GitHub Copilot helped generate a Python program that copied data in dependency order through PostgreSQL binary COPY, handled selected Oracle interval and numeric values, and advanced PostgreSQL sequences after loading.

The script and its configuration remained in the repository instead of becoming an undocumented one-time operation.

The author then verified matching row counts between Oracle and PostgreSQL.

For a production migration, data movement needs its own design for consistency, downtime, change capture, throughput, encryption, reconciliation, retry, and rollback. A generated copy script for a small lab is evidence of reproducibility, not a substitute for a production data-migration architecture.

Validation Was Layered

The experiment used four layers so failures could be isolated.

The first layer checked the PostgreSQL catalog, required objects, and representative analytical queries with EXPLAIN and EXPLAIN ANALYZE.

The second layer called every public workload routine and exposed runtime defects that compilation missed, including composite return mismatches, inconsistent customer-ID types, missing package-state defaults, and a remaining Oracle type reference.

The third layer verified business effects through a rollback-safe order workflow. It created orders, validated fields and item rows, updated an item and its order total, rolled back, reconnected, and confirmed the orders were absent.

The fourth layer ran weighted concurrent calls. Four users completed 287 calls across nine transaction types with zero errors in the published lab run.

That final number is not a production benchmark. It demonstrates that the converted routines survived one controlled concurrent test after lower-level correctness checks passed.

AI Accelerates Iteration but Does Not Own the Decision

The human operator made the architecture decisions, directed the investigation, reviewed generated code, and validated results.

The migration extension used model assistance for conversion and review. GitHub Copilot generated supporting data-copy, repair, and test code under direction. PostgreSQL compilation and executable tests supplied deterministic evidence.

This division of responsibility matters.

Do not accept a migration because the model reports high confidence. Require source extraction, dependency analysis, target compilation, reviewable diffs, data reconciliation, business tests, workload tests, security checks, and application-owner approval.

AI is most useful when it reduces the time between a finding and the next verified experiment.

Security and Governance Considerations

The workflow connects to a privileged Oracle source, a PostgreSQL target, and a Microsoft Foundry deployment.

Use isolated migration environments and scratch targets. Never point exploratory generated DDL at a production application database.

Protect:

• Source and target credentials

• Foundry endpoint and key

• Extracted schema and procedural code

• Generated reports and conversion logs

• Sample or copied data

• Git history and build artifacts

• Container images and dependencies

Prefer supported identity mechanisms and secret stores instead of embedding credentials in repository files or shell history. Review whether source code, schema names, comments, or data samples can be sent to the selected model under organizational policy.

Generated routines need the same secure-code review as human-written database code.

Who Should Care?

Database modernization teams should care because assessment, conversion, compiler feedback, and validation can remain in one reproducible project.

Oracle developers should care because packages, transaction control, collections, state, and indexing need architectural translation rather than syntax replacement.

PostgreSQL engineers should care because target compilation and runtime behavior provide the evidence that model output cannot.

Application owners should care because business equivalence must be proven through application-facing calls and effects.

Security teams should care because source code, credentials, models, generated artifacts, and scratch databases form a sensitive migration environment.

Practical Cloud Engineer Takeaway

Choose one bounded Oracle schema with a known application workload and no production write path.

Baseline the source first: compile its objects, run representative transactions, capture row counts, document public routines, and record expected business effects.

Create a migration project in source control and use an isolated supported PostgreSQL scratch target. Review every generated artifact and preserve the complete conversion log.

Build validation in increasing layers:

• Target compilation and dependency checks

• Row-count and data reconciliation

• Invocation of every public routine

• Business-effect tests with rollback

• Representative analytical queries and plans

• Concurrent workload replay

• Security, failure, and recovery tests

Classify every remaining divergence by owner, severity, evidence, and go-live condition.

Do not estimate production readiness from the number of compiled objects. Estimate it from the unresolved semantic, transactional, operational, and application risks.

Bottom Line

Microsoft's Oracle-to-PostgreSQL VS Code walkthrough demonstrates a promising integrated migration loop: extract, assess, convert, review, compile, repair, copy data, and validate from one reproducible workspace.

The experiment also proves why conversion is only the beginning. Oracle packages, state, transactions, collections, indexing, timing, exceptions, and business behavior require explicit engineering decisions and executable evidence.

The target and parts of the workflow remain preview or unsupported in the tested combination, so this is a lab pattern rather than a production support statement.

The right next step is a bounded proof of concept on a currently supported source and target, with human-reviewed conversion artifacts and layered tests that prove data, transactions, business effects, and workload behavior before migration scope or timelines are committed.

Sources

Microsoft for PostgreSQL evaluation, published August 14, 2026: https://techcommunity.microsoft.com/t5/microsoft-blog-for-postgresql/oracle-to-postgresql-in-vs-code-assessment-conversion-and/ba-p/4544728

Microsoft PostgreSQL extension for Visual Studio Code: https://marketplace.visualstudio.com/items?itemName=ms-ossdata.vscode-pgsql

Published walkthrough artifacts and validation scripts: https://github.com/FranckPachot/test-ora-mig/tree/walkthrough-validation/.github/postgres-migrations/walkthough-validation

Azure HorizonDB product page: https://azure.microsoft.com/products/horizondb

PostgreSQL extension issue tracker: https://github.com/microsoft/vscode-pgsql/issues

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz