Migrating from Legacy PDM to Modern PLM: A Practical Guide

Every manufacturer accumulates product data debt. Years of engineering work live in shared drives, legacy PDM systems that are three versions out of date, spreadsheets that only one engineer fully understands, and drawing archives organized by tribal knowledge rather than any rational scheme.

When the decision comes to migrate to modern PLM, the immediate instinct is to treat migration as a technical problem: extract data from the old system, transform it, load it into the new one. That instinct is understandable — but it misses where the real work is.

The real work is data triage: deciding what to migrate, what to archive, and what to simply let go. That decision requires understanding your data better than you probably do today.

Prerequisites

The data audit you can't skip

Before writing a migration plan, audit your legacy data. A one-week data audit on a sample of 500–1,000 parts will tell you:

• What percentage of parts have complete required fields (part number, description, revision, unit of measure)
• What percentage of CAD files are in formats the new PLM can natively handle
• Whether your revision history is trustworthy or a series of ad-hoc overrides
• How many duplicate part numbers exist (more than you think)
• Whether your BOM structures are intact or fragmented

Typical audit findings for legacy PDM systems:

| Issue | Typical Rate | |-------|-------------| | Missing required fields | 15–35% of parts | | Duplicate or ambiguous part numbers | 3–8% | | CAD files orphaned (no BOM reference) | 10–25% | | BOM structures with broken parent-child links | 5–15% | | Legacy CAD formats (pre-2015) | 20–40% |

If your audit is in these ranges, your migration is larger than you initially scoped. Adjust expectations before committing to a timeline.

Triage categories

Before migrating anything, categorize your product data:

Active (migrate fully): Products actively shipped or under development. Full BOM, latest revision, complete history where trustworthy.

Legacy active (migrate structure, archive files): Products still shipped but not under active development. Migrate the released BOM structure; archive CAD files in read-only storage linked from PLM.

Historical (archive only): Discontinued products, superseded designs, anything not manufactured in the last 3–5 years. Archive in a structured read-only system; do not import into PLM.

Discard: Duplicate entries, test data, clearly erroneous records. Delete before migration begins.

The goal is to reduce the active migration scope as much as possible. Every part you archive or discard instead of migrating saves hours of cleansing and validation work.

Migration Strategy: Wave-Based Approach

Migrate in waves organized by product family, not by data type. Migrating all CAD files first, then all BOMs, then all documents creates a period where the data is partially in each system with no coherent picture in either. Migrating complete product families preserves traceability.

Wave 0: Infrastructure and tooling (Weeks 1–4)

Before migrating any production data:

1. Configure the new PLM environment (classification, lifecycle states, workflows)
2. Build and test migration tooling — ETL scripts, import templates, validation queries
3. Run a dry run migration on 50–100 non-critical parts
4. Define the data quarantine workflow in the new PLM system
5. Train the migration team (typically 2–4 people from engineering and IT)

Wave 1: Pilot family (Weeks 5–12)

Select one product family with moderate complexity — not your simplest (doesn't expose real problems) and not your most complex (too much risk for a pilot).

Migration steps for each wave:

Step 1: Extract from legacy system

Export from the legacy PDM system using its native export capability or API. For shared drives, use a directory crawler that builds a manifest of file paths, names, and modification dates.

# Example: Extract BOM data from legacy PDM via CSV export
# This is system-specific; most PDM tools have a BOM export function
legacy_pdm_cli export-bom \
  --family "PRODUCT_FAMILY_A" \
  --format csv \
  --include-attributes all \
  --output ./migration/wave1/bom_export.csv

# Validate row count and spot-check against manual record
wc -l ./migration/wave1/bom_export.csv

Step 2: Cleanse and transform

Run validation checks on the exported data:

import pandas as pd

df = pd.read_csv('./migration/wave1/bom_export.csv')

# Check required fields
required = ['part_number', 'description', 'revision', 'unit_of_measure', 'lifecycle_state']
for field in required:
    missing = df[df[field].isna() | (df[field] == '')]
    if len(missing) > 0:
        print(f"WARNING: {len(missing)} rows missing {field}")
        missing.to_csv(f'./quarantine/{field}_missing.csv', index=False)

# Check for duplicate part numbers
dupes = df[df.duplicated('part_number', keep=False)]
if len(dupes) > 0:
    print(f"WARNING: {len(dupes)} duplicate part numbers found")
    dupes.to_csv('./quarantine/duplicates.csv', index=False)

# Remove quarantine rows from migration set
clean_df = df[~df['part_number'].isin(dupes['part_number'])]
print(f"Clean rows ready for import: {len(clean_df)}")

Step 3: Import into PLM

Use the new PLM system's bulk import API or import template. Most enterprise PLM systems support CSV/Excel bulk import for parts and BOMs.

Validate after import:

• Row count in PLM matches clean export count
• Spot-check 20–30 parts manually against legacy system
• Verify BOM parent-child relationships are intact
• Confirm CAD file attachments resolve correctly

Step 4: Quarantine handling

Parts flagged during cleansing go into PLM in a "Data Quarantine" lifecycle state:

• Visible and searchable in PLM
• Cannot be released or used in new assemblies until remediated
• Assigned to an owner for remediation
• Tracked on a quarantine dashboard

This approach is faster than cleaning everything before import and avoids blocking the migration on data quality debates.

Subsequent waves

Waves 2–N follow the same pattern. Each wave takes progressively less time as the migration team builds proficiency and the tooling stabilizes. Typical wave cadence:

• Wave 1 (pilot): 8 weeks
• Wave 2: 6 weeks
• Waves 3–5: 4 weeks each
• Final wave (complex legacy): 8 weeks

CAD File Migration

CAD files require special handling because:

1. Native formats are version-specific — a CATIA V5 file won't open in CATIA V6 without conversion
2. Large assembly files can take minutes to hours to process individually
3. CAD files have internal references to other files — those references break if paths change

Format strategy

For each CAD file in scope, assess:

| Situation | Recommended Action | |-----------|-------------------| | Native format supported by new PLM | Import as-is | | Older version of supported CAD | Import as-is; resave in current version on first check-out | | Unsupported legacy CAD (I-DEAS, Pro/E pre-2010) | Convert to STEP + PDF/A drawing | | SolidWorks / Inventor migrating to different CAD | Import STEP + maintain native as archive |

STEP conversion preserves geometry but loses associativity (parametric relationships, assembly constraints). If the assembly will never be modified again, STEP is sufficient. If it will be modified, native-to-native conversion is necessary and expensive.

Reference management

CAD assemblies reference their component files by path. When migrating to PLM, those paths change from file system paths to PLM vault references. Most PLM CAD connectors handle this automatically during check-in — but only if all referenced files are checked in to PLM first.

Migration order matters: check in leaf-level components before sub-assemblies, sub-assemblies before top-level assemblies.

Migration order:
1. Raw material parts (no children)
2. Purchased parts (no children)
3. Manufactured parts (children = raw materials + purchased)
4. Sub-assemblies (children = manufactured parts)
5. Top-level assemblies (children = sub-assemblies)

Cutover Planning

The cutover is the most politically sensitive phase of the migration. Engineering teams will resist giving up the shared drives and legacy PDM access — especially for products they're actively working on.

Cutover approach: hard cutover by product family

After each wave is validated:

1. Announce the cutover date 4 weeks in advance
2. Freeze the legacy system for that product family (read-only)
3. Train all users on the new PLM for that family
4. Set the legacy system to read-only on the cutover date
5. Communicate that all new work must happen in PLM

The "read-only" framing is important. Engineers need to know the legacy data isn't being deleted — it's just not the working system anymore. This reduces resistance significantly compared to "we're shutting down the old system."

What to do with the legacy system after cutover

Archive the legacy system's database in a format that can be read without the application (SQL dump, CSV export). Keep it accessible for 3 years for reference — engineers will occasionally need to look up historical data that wasn't in scope for migration.

After 3 years, assess whether the archive is still being accessed. If not, it can be moved to cold storage or formally decommissioned.

Validation Framework

Before declaring each wave complete:

| Check | Method | Pass Criteria | |-------|--------|---------------| | Row count | Automated | PLM count ≥ 98% of source count (2% tolerance for intentional exclusions) | | Required fields | Automated | 100% of non-quarantine records complete | | BOM integrity | Automated | 0 broken parent-child references | | CAD file resolution | Automated | 100% of CAD file references resolve in PLM | | Revision accuracy | Manual sample | 20 random parts: PLM revision matches legacy | | Search accuracy | Manual | 10 known parts found by part number and description |

Common Failure Modes

Trying to clean all data before starting. Data quality problems in legacy systems are often impossible to fully resolve without going back to the original engineer who created the part. Set a "good enough" threshold for migration and quarantine the rest.

No hard cutover date. Without a mandatory cutover, engineers will use both systems. Within 6 months, the legacy system will have newer data than PLM for some products — the migration has failed.

Migrating test and prototype data. Prototype part numbers, early-concept CAD files, and discarded designs pollute the PLM database. Filter these out during triage.

Underestimating CAD file count. CAD directories on shared drives accumulate derivative files (rendered images, exported PDFs, backup copies) alongside the actual native CAD files. Audit the directory before scoping; actual CAD files are typically 20–40% of the total file count.

Related Resources

• [[PLM for SMBs]] — starting fresh vs. migrating legacy data
• [[PLM Enterprise Rollout]] — migration at multi-site scale
• [[PLM Data Governance]] — keeping PLM data clean after migration
• [[What Is PDM]] — understanding what you're migrating from