Deploy converted schemas with the Setup Experience

The Schema Conversion Setup Experience automatically generates instructions and scripts as the conversion workflow finishes. Use these files to deploy converted schemas to Azure Database for PostgreSQL. Generating the files doesn't deploy the schemas to your destination. You review them and run the generated PowerShell or Bash script in your deployment environment.

For instructions on opening the setup files from a completed conversion, see Prepare deployment with the Setup Experience in the tutorial.

Review the generated files

The setup directory depends on how many Oracle schemas you select for conversion. Use the applicable path relative to the workspace root:

Replace <migration-project> with the migration project folder name, such as Mig001. If you select one schema, replace <schema-name> with the selected Oracle schema folder name, such as HR. If you select multiple schemas, _migration is the actual folder name, not a placeholder.

The location reflects the selected Oracle schemas, not the number of PostgreSQL schemas included in the package. Review setup_instructions.md for the package's deployment scope.

Keep the setup directory inside the complete migration project. The runners reference the conversion session's deploy.sql in the sibling convert directory; copying only the setup directory isn't sufficient.

Review the generated instructions and deployment SQL before running them. Confirm that the SQL includes the object corrections you intend to deploy. If you transfer the project to another environment, preserve its directory structure and follow your organization's data-handling requirements. Remove credentials and other secrets from files you share.

Prepare the destination

Use the requirements in your generated setup_instructions.md, rather than copying requirements from another conversion:

• Server and client versions. Prepare an Azure Database for PostgreSQL flexible server with the required PostgreSQL version. The psql client's major version must match the conversion-server major version recorded in the generated setup package. Install that client on the computer that runs setup, and make it available on PATH. Setup can create a database on your server, but doesn't provision the Azure server.
• Shell and file access. Use PowerShell 5.1 or later on Windows, or Bash on Linux or macOS. The runner needs write access to its logs and reports directories.
• Network access. Allow the setup computer to connect to the Azure Database for PostgreSQL destination server and PostgreSQL port.
• Extensions. Review the required extensions and add supported extensions to the Azure Database for PostgreSQL destination server's allow list before deployment. See Allow extensions in Azure Database for PostgreSQL.
• Permissions. Use an account with the database, schema, object-creation, and extension-installation permissions specified in the generated instructions. New-database mode also requires permission to create the database.
• Authentication. Use the script's hidden password prompt, a PostgreSQL password file, or your organization's approved secret-management process. Don't embed passwords in deployment scripts.

Confirm that the client is available:

psql --version

The generated instructions reflect the conversion environment, including its PostgreSQL version and extension requirements. Review any destination differences before deployment.

Choose a database mode

Both runners support these modes:

For an interactive run, the script prompts for missing host, user, and database values. Review the displayed destination, database mode, schemas, and operation before confirming.

Check readiness without deploying

Open a terminal in the generated setup directory. Choose the command for your operating system and intended database mode:

Validate-only mode connects to the server and writes local reports and logs. It doesn't create the target database, install extensions, or deploy converted objects.

The readiness checks cover connectivity, PostgreSQL version, database encoding and locale settings, permissions, target-schema occupancy, and extension availability. Review warnings as well as blocking failures.

In new-database mode, validation uses the maintenance database because the destination database doesn't exist yet. Checks that require the destination database are marked as skipped. A successful validate-only run isn't confirmation that those skipped checks passed.

When validation completes successfully, review validation_report_<timestamp>.md in the reports directory. Resolve reported issues before deployment. If validation stops early, check the console output first, then any log or report that was created.

Deploy the converted schemas

Use the same destination and database mode that you checked. From the setup directory, run the appropriate command without -ValidateOnly (PowerShell) or --validate-only (Bash):

The runner prepares the database, checks readiness, installs required supported extensions, executes the converted deployment SQL, and verifies the resulting objects and extensions.

Review the deployment SQL before approving a non-empty destination because it can change existing objects.

Use setup_instructions.md for optional port, TLS, locale, and automation parameters. For a non-interactive run, provide the host, user, database, and authentication details in advance. A non-empty existing target also requires explicit acknowledgment through -AllowNonEmptyExisting on Windows or --allow-nonempty-existing on Linux or macOS.

Review deployment results

Read the deployment results before continuing to data or application validation. A conversion status alone doesn't confirm deployment to this destination.

Validate-only runs produce a validation report instead of a deployment report. An early failure, such as a file-access or shell-version problem, might leave only console output.

Use the runner's exit code together with these outputs:

Continue automation only for exit code 0. For any other code, review the available outputs and resolve the reported issues before proceeding.

Validate the deployed schema

Successful setup doesn't establish behavioral equivalence with Oracle or production readiness. Independently test data handling, dependencies, business logic, and application behavior in the destination environment.

Review any objects or extensions that weren't deployed and complete their remediation. Apply separately managed security configuration and revoke temporary setup privileges when they're no longer required.

Related content

• Tutorial: Convert Oracle schemas to Azure Database for PostgreSQL
• Review converted objects in Conversion Object Explorer
• View the HTML report for Oracle schema conversion
• Best practices for Oracle to Azure Database for PostgreSQL schema conversion