Data Pump Dump File Version Compatibility for Downward Migration

Direct answer

No metadata category is guaranteed to survive a Data Pump VERSION downgrade simply because the parameter is set. expdp ... VERSION=target_release writes the requested release level into the dump-file header, but impdp still rejects objects that depend on features newer than the target release. Core relational metadata—tables, columns, constraints, indexes, and grants—usually survives only when those objects do not use release-specific features introduced after the target version. Objects that cannot be represented are omitted, replaced with defaults, or skipped with Data Pump warnings, and dependent objects may be removed to keep the metadata consistent.

Confirmed behavior versus likely behavior

Confirmed

• VERSION is a header declaration and compatibility filter, not a downgrade converter.
• VERSION=COMPATIBLE follows the database COMPATIBLE initialization parameter, which can be higher than the intended target and is therefore not sufficient by itself for downward migration.
• An acceptable dump-file header does not guarantee that the target can load the metadata.

Likely, requires verification

• Object statistics, advanced options, partitioning features, and newly added metadata columns are the most release-sensitive categories.
• Behavior is not consistent across major releases for objects introduced after 19c; 21c or 23ai-only metadata may have no defined representation in 19c or 12.2.
• A staged export through an intermediate release retains more information only when the direct source-to-target downgrade mapping is weaker than consecutive jumps, or when direct import into the target is restricted. It cannot recover features omitted by the first VERSION=target export.

Steps for this case

1. On a nonproduction source, export the candidate schema with an explicit release string, for example VERSION=target_release, and review the export log for skipped objects and dependent-object removals.
2. Copy the dump file to a test database running the exact target release and patch level.
3. Run impdp ... SQLFILE=preview.sql SHOW=Y to preview the DDL without executing it, then compare object counts and DDL against the source using DBMS_METADATA.
4. Repeat for each object class and feature in use, including indexes, constraints, partitioning, advanced options, and post-19c objects.

Missing diagnostic detail

Provide the exact source release, target release, and COMPATIBLE setting for both databases. That combination changes whether a single VERSION export is adequate or whether an intermediate export is required.

Assumptions and uncertainty

This answer assumes standard Data Pump export and import behavior across Oracle 12.2, 19c, 21c, and 23ai. Patch-set differences and release updates can alter which objects are skipped, so test on the exact patch levels planned for production rather than only the release family. Do not rely on undocumented silent omissions.