Project file is corrupted: Unresolved need for automatic schema migration in Premiere Pro

Short answer

As of the current public documentation, Adobe has not announced an automatic schema migration tool for legacy .prproj files, and the Recovery workflow is not one — it rebuilds a new project from whatever parses, it does not convert schemas. So the three questions you raise (when to offer migration, how to preserve metadata, and where it would live) are genuinely unresolved design questions, not features you have missed. What follows separates what is established from what is speculative, and suggests criteria a migration tool would need to meet.

What is confirmed vs. assumed

Confirmed behavior: Premiere Pro project files carry an XML schema version, the parser validates against the host application's schema before building the project tree, and a mismatch or malformed section triggers the "Project file is corrupted" dialog. File > Open Project > Recover skips malformed sections and writes a new file; it does not preserve the original schema and may overwrite unrecoverable content.

Assumed, not verified: the claim that newer Premiere Pro versions categorically cannot open older project files. In practice, Premiere Pro has historically opened older projects by upgrading them on load (often writing a converted copy). The hard failures tend to involve deprecated elements, third-party plug-in data, or structural corruption rather than age alone. Verify against the specific version pair you are hitting before assuming schema age is the cause.

Criteria for offering automatic migration

1. Version gap detection: read the schemaVersion attribute on <PremiereProject> and compare it to the host's supported range. Migration should be offered only when the gap maps to a known, tested transform — not attempted blindly on unknown versions.
2. Lossless pre-check: before converting, the tool should enumerate elements and attributes that have no mapping in the target schema (deprecated effects, plug-in subtrees, custom tags) and report them, so the user can accept or abort.
3. Non-destructive operation: always write a new file and keep the original untouched, since Recovery already demonstrates the risk of overwriting the only copy.

Preserving metadata and custom XML

The hard part is not renaming known elements — it is the unknown ones. A safe migrator would need a pass-through policy: any element the schema transform does not recognize should be carried into a namespaced extension container rather than dropped, so plug-in data and custom tags survive even if Premiere Pro itself ignores them. A diff report (elements mapped, elements passed through, elements dropped) would be the minimum bar for calling the migration "without data loss."

Recovery integration vs. separate tool

Integrating migration into Recovery is the more coherent design: both already parse-then-rebuild, and the user reaches for Recovery exactly when schema or structure problems block a normal open. The distinction worth keeping is intent — Recovery should stay "salvage what parses," while migration should be "convert what is valid but outdated," with a clear prompt showing which mode is running. One missing detail would sharpen this: the exact Premiere Pro versions of the source and target files, since some version pairs already convert on open and the real problem may be a single deprecated element rather than the schema as a whole.