I’ve dealt with this exact scenario twice during 11.1 M030 to 12.0 migrations in large Oracle environments. Let me give you a complete rundown of the root cause and the remediation steps we used successfully.
Root Cause:
In Windchill 11.1, the mastership reference for WTPart was stored as a column-level FK (MASTERSHIPREFERENCE) directly on the WTPART table. In 12.0, PTC refactored this into a separate association table (WTPARTMASTERSHIPREF) as part of the distributed ownership model changes. The upgrade script first migrates the data into the new table, then attempts to drop the legacy column. The issue arises when the migration step in a prior CPS (specifically before CPS04) left behind duplicate or partially migrated rows in WTPARTMASTERSHIPREF without properly NULLifying the source column first — the FK constraint is then still enforced at drop time.
Remediation Steps (tested on Oracle 19c):
Step 1 — Take a full RMAN backup. Non-negotiable before proceeding.
Step 2 — Identify the exact orphaned references:
SELECT r.IDA2A2, r.WTPART_REF, p.IDA2A2 AS PART_IDA
FROM WCADMIN.WTPARTMASTERSHIPREF r
LEFT JOIN WCADMIN.WTPART p ON r.WTPART_REF = p.IDA2A2
WHERE p.IDA2A2 IS NULL;
Rows returned here are true orphans (no matching WTPart) and are safe to remove.
Step 3 — For rows where the WTPart still exists (your 312 rows), check if the mastership data was already correctly migrated to the new schema structure:
SELECT r.IDA2A2, r.WTPART_REF, p.MASTERSHIPREFERENCE
FROM WCADMIN.WTPARTMASTERSHIPREF r
JOIN WCADMIN.WTPART p ON r.WTPART_REF = p.IDA2A2
WHERE p.MASTERSHIPREFERENCE IS NOT NULL;
If MASTERSHIPREFERENCE on WTPART still has a value AND a row exists in WTPARTMASTERSHIPREF, the migration was partial. The data is duplicated and the WTPART column value is the one to preserve.
Step 4 — Apply PTC’s supplemental script from CS359147 (request it explicitly from PTC Support referencing this CS article and your case). What it does: it first disables the FK constraint, re-validates migrated rows, sets MASTERSHIPREFERENCE to NULL on WTPART rows where WTPARTMASTERSHIPREF already has the correct record, then re-enables the constraint. It does NOT delete live business data — it ensures the migration is complete before the drop is retried.
If you cannot get the script in time, you can manually achieve the same effect:
-- Disable the constraint temporarily
ALTER TABLE WCADMIN.WTPARTMASTERSHIPREF
DISABLE CONSTRAINT FK_WTPART_MASTERSHIP_REF;
-- NULL out the legacy column where migration is confirmed complete
UPDATE WCADMIN.WTPART p
SET p.MASTERSHIPREFERENCE = NULL
WHERE EXISTS (
SELECT 1 FROM WCADMIN.WTPARTMASTERSHIPREF r
WHERE r.WTPART_REF = p.IDA2A2
);
COMMIT;
-- Re-enable and validate
ALTER TABLE WCADMIN.WTPARTMASTERSHIPREF
ENABLE VALIDATE CONSTRAINT FK_WTPART_MASTERSHIP_REF;
Step 5 — Resume the upgrade using the checkpoint mechanism:
cd <WT_HOME>/bin
windchill upgrade -resumeFromStep SchemaUpdateStep_WTPart_col_drop
Verify the step name in your upgrade_checkpoint.xml first as sys_arch_delacroix noted — it may vary slightly by CPS patch level.
Step 6 — After successful upgrade, run the post-migration validation:
windchill wt.upgrade.tools.ValidateUpgradedDB -full
Important: Do not skip the RMAN backup at Step 1. If the constraint re-enable at Step 4 fails with additional violations, stop and engage PTC Support directly — it means there are more complex data integrity issues beyond the typical migration gap.
This resolved the issue cleanly in both environments I handled. The 12.0 schema ends up correct and no mastership data was lost.
This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.