Data migration is where a PLM program stops being a design exercise and becomes an operational commitment. Once data moves, the business is deciding what product truth will exist in the new platform on day one and what legacy ambiguity it is willing to carry forward. Cutover then transfers control of parts, documents, BOMs, changes, and release history to that new environment. Engineering, manufacturing, quality, and service all need to trust that the handoff preserved current records, required evidence, and usable relationships. If scope is too broad, cleansing is weak, or validation is shallow, the new PLM will simply expose old confusion faster. This chapter explains how to define migration scope, cleanse data, validate what moved, and execute cutover and hypercare without breaking continuity of product governance.
14.1 Migration Scope and Principles
The first migration decision is not how to load the data. It is what deserves to move at all. Most organizations begin with a reflex to migrate everything, then discover that indiscriminate migration raises cost, lengthens timelines, and brings legacy confusion into the target system. A better starting point is to define which records the business truly needs to operate, support the installed base, remain compliant, and preserve traceability after go-live.
Migration scope: the defined population of records, relationships, and history that will move into the target PLM for active use or controlled reference. Scope should be based on business purpose, not storage convenience. Active released product data is usually in scope. So are current in-work records needed by live programs, controlled documents required for quality or regulatory evidence, and the history needed to service products already in the field. By contrast, obsolete local copies, abandoned prototypes, personal folders, and historical records with no operational or legal value are often better archived than migrated.
Most companies benefit from a simple four-way disposition model:
- Migrate as active data: records needed for day-one work in the new PLM.
- Migrate as historical reference: records needed for traceability, service, or audit, but not routine editing.
- Recreate or manually remediate: high-value records whose source quality is too poor for direct conversion.
- Archive only: legacy content that should remain retrievable but does not belong in the active PLM environment.
This model forces deliberate tradeoffs. A heavily reused assembly with active service obligations may justify migration of prior revisions and change history. A retired local variant with no installed base may not. A document with legal significance may need retention and searchability, but not full relationship reconstruction if the product is already out of commercial use. The test is simple: does the record strengthen the future operating model?
System boundaries matter as well. Scope should reflect the future-state ownership model, not the habits of the legacy environment. If PLM is intended to own governed product definition, then parts, documents, drawings, structures, revisions, release states, and controlled change history belong in scope. If ERP, MES, or QMS owns execution and transactional history, those records should not be pulled into PLM merely because they sat near product data before.
Migration principle: the rule used to interpret legacy data in the target model. Every program should establish a small set of such principles early. Useful examples include: only controlled current-state documents will be migrated as releasable records; identifiers will be preserved wherever possible; legacy naming conventions will not override future-state classification rules; and relationships required for release, where-used analysis, and compliance traceability must be restored before go-live. These principles prevent one-off compromises that gradually erode trust in the new environment.
The concept of a minimum viable record is especially helpful. Minimum viable record: the smallest set of attributes, relationships, and lifecycle controls a migrated object must have to behave correctly in the future-state PLM. For a part, that often means identifier, description, class, revision, lifecycle state, ownership, and required links to governing documents or structures. For a document, it means type, revision, status, owning object, and evidence of the current approved version. Records that cannot meet this standard should not quietly enter active PLM as if they were trustworthy. They should be repaired, recreated, or archived according to policy.
Work in progress needs a separate policy. Open change objects, pending approvals, supplier responses, draft BOMs, and prototype structures rarely convert cleanly if they are treated like stable released data. Some in-flight items should be stabilized and migrated as working records. Some should be finished in the legacy system and moved only after release. Others should be closed administratively and recreated in the target platform. These rules should be decided by object type and workflow state before testing and training begin, not during the cutover window.
Wave design can simplify scope, but the wave boundary still has to be operationally coherent. Product lines that share large amounts of common structure, approved source logic, or service history should not be split carelessly. Once scope is set, it must also be governed. Late requests will appear constantly: one more site archive, one more project folder, one more spreadsheet someone believes is essential. A small governance group should own exceptions and keep asking the same question: does this data improve the future source of truth, or does it merely preserve legacy clutter in a new place?
14.2 Data Cleansing Playbook
If migration scope decides what will move, data cleansing decides whether what moves will be trusted. This is where the real condition of the legacy environment becomes visible. Part masters that looked stable turn out to be duplicated across sites. Drawings exist in several almost-identical copies with inconsistent revision labels. BOMs contain obsolete substitutes, missing units of measure, and informal notes that were carrying business meaning outside any governed field. Cleansing is therefore not a cosmetic exercise. It is the point at which the company decides whether the new PLM will inherit ambiguity or enforce a higher standard of product truth.
Data cleansing: the controlled process of identifying, correcting, standardizing, enriching, and, where necessary, excluding legacy records so they conform to the target operating model. The work should start with two things at the same time. First, the program needs a fact base: duplicate counts, missing attributes, broken links, invalid states, unclear current versions, and weak BOM structures. Second, it needs stable target standards for naming, object classes, mandatory attributes, units of measure, revision semantics, lifecycle states, and relationship rules. Cleansing teams cannot work effectively if either side is missing. They need to know both what is wrong and what “good” looks like.
Part master cleansing usually creates the largest workload. Duplicate detection is the obvious issue, but classification, description quality, owner assignment, and unit consistency are just as important. The team needs rules for deciding when two records represent the same real-world item and when they must remain distinct because source control, compliance treatment, or design intent differs. Deduplication should never rely on string matching alone. Engineering or data stewards need to confirm interchangeability before a record is merged or retired. High-confidence duplicates should be resolved quickly, while ambiguous cases move into a controlled exception queue.
Document and drawing cleansing often exposes deeper control problems. File names may contain unofficial version codes, project abbreviations, or local conventions no one ever formalized. The most recently modified file may not be the current approved version. Some documents may exist both in vaults and shared drives, with no evidence of which copy governed release. The cleansing playbook therefore needs a clear rule for identifying the authoritative version, the correct document type, and the proper relationship to the affected part or assembly. Where certainty cannot be established, the safer choice is often to archive the content as historical reference rather than elevate it into active controlled status.
BOM cleansing requires more than loading structure. Quantities, units, reference designators, effectivity notes, alternate parts, and where-used integrity all need review. Some legacy BOMs contain components inserted for one plant, one shortage, or one temporary deviation and never removed. Others contain notes that imply configuration logic but were never modeled explicitly. During cleansing, these patterns should be resolved, not copied forward. If the new PLM is expected to support proper configuration and change control, informal logic hidden in notes or spreadsheets has to become governed structure or governed rule.
Relationship repair is a separate discipline. A part without its controlling drawing, a specification without the item it governs, or a released structure with missing child links may technically load into PLM and still be unusable. The team should therefore treat relationships as first-class data, not as optional metadata. This matters especially for changing history and releasing evidence. If the business expects to analyze impact, support audits, or trace field issues, it needs not only the objects but also the links among them.
A practical cleansing playbook usually follows this sequence:
- Profile: measure duplicates, missing attributes, broken links, and invalid states.
- Standardize: apply target naming, classes, units, and attribute rules.
- Deduplicate: resolve redundant items and documents with business signoff.
- Enrich: populate missing mandatory attributes and ownership fields.
- Repair relationships: reconnect parts, documents, BOMs, and change records.
- Quarantine exceptions: isolate records that cannot meet target standards in time.
- Approve for migration: move only records that meet the agreed readiness threshold.
The operating model behind the playbook matters as much as the steps. IT and migration specialists can automate profiling, mapping, and some standardization, but they cannot decide business truth. Engineering stewards, document owners, manufacturing representatives, quality leads, and sometimes supplier-management teams need to own decisions in their domains. Many successful programs create cleansing squads by product area. These groups work from one enterprise rule set but resolve local ambiguities quickly.
Open changes and in-flight workflow objects need explicit cleansing rules as well. Legacy change requests with incomplete impact analysis may be migrated as active objects, closed administratively, or archived and reinitiated in the target system depending on business need. Partial approval histories may be preserved for reference or translated into the new workflow model. What matters is that these choices are made by policy, not by improvisation during the final weeks.
One final discipline is essential: stop dirty data from re-entering the pipeline while cleansing is underway. If users continue creating new records in legacy systems without the same standards the migration team is applying, the defect backlog simply regenerates. A controlled creation policy, interim governance rules, or at least a clear freeze-and-delta strategy is needed. Cleansing is not finished when the historic backlog is fixed. It is finished when the cutover data set is stable enough that the same defects are not reintroduced through ongoing work.
14.3 Migration Validation and Reconciliation
Many PLM programs declare migration success because the load jobs completed and the record counts look plausible. That is not validation. It is only evidence that data moved. Real migration validation asks a harder question: does the target system now contain the right product truth, with the right relationships, lifecycle meaning, and usability for the processes that depend on it? Until that question is answered, the program has not proven readiness for cutover.
Migration validation: the structured confirmation that migrated records, relationships, states, and history are complete, accurate, and usable in the target PLM. Reconciliation: the comparison of source and target populations, attributes, and behavior to explain differences and confirm that only intended transformations occurred. These disciplines are related but not identical. Validation proves operational correctness. Reconciliation proves that the migration behaved as designed.
The first layer is technical completeness. Are all expected records present? Did files load without corruption? Were required attributes populated according to the mapping rules? Are identifiers unique and stable? These checks are necessary, but they are only the floor. A technically loaded BOM that points to the wrong revision or lacks key child relationships is still a business failure. The next layer is business validation. Engineering should confirm that current released revisions are correct, that related drawings and documents are linked, and that structures represent the intended baseline. Manufacturing may need to confirm that downstream handoff remains usable. Quality may need to confirm that controlled documents, change histories, and compliance evidence retained the context needed for audits and investigations.
Risk-based validation is usually the right approach. Not every migrated object deserves the same depth of review. High-risk assemblies, heavily reused modules, regulated records, service-critical parts, and objects with complex change history should receive deeper validation, often close to one hundred percent. Lower-risk historical or reference content can be checked through structured sampling. The key is that sampling must be deliberate, with clear rationale and clear defect thresholds that would trigger broader review.
Reconciliation should occur at several levels. Record counts by object type are the starting point. If the source contains 50,000 active released parts and the target contains 49,200, the program needs an explicit explanation for the difference. Perhaps duplicates were merged. Perhaps some records were archived intentionally. Perhaps a load step failed. Attribute reconciliation is the next layer. Descriptions, classes, units, owners, lifecycle states, revision values, and effectivity indicators should match the approved transformation rules. Relationship reconciliation is equally important. A part may exist in the target, and the count may reconcile, yet its controlling drawing is missing, its where-used context is broken, or its parent assembly reflects an outdated child revision. Validation therefore has to include relationship integrity checks as well as record counts.
Scenario-based validation is the bridge from data quality to operational readiness. The program should test real business scenarios using migrated data: locating a released part and its current documents, comparing revisions across a multi-level structure, initiating a change against a migrated assembly, releasing a revised document, or handing a released structure to a downstream integration. These scenarios prove not only that the data is present, but that users can work with it as intended. A migration that passes counts but fails live scenarios is not ready.
Defect management and signoff are part of validation, not an afterthought. The program needs clear categories for critical, major, and minor defects, a triage team empowered to assign ownership, and decision thresholds for what must be fixed before cutover. IT can sign off on load performance and technical completeness. Business owners should sign off on product truth within their domains. When validation and reconciliation are treated seriously, go-live becomes a controlled business decision rather than an act of optimism.
14.4 Cutover Planning and Hypercare
Cutover is the moment when the migration plan meets real business time. Up to this point, the team can still rerun loads, extend rehearsals, and treat defects as project work. At cutover, the question changes: how will the organization stop transacting in the legacy environment, move the final delta of product truth, open the new PLM, and keep engineering, manufacturing, quality, and suppliers operating without confusion? That is why cutover should be designed as a business transition runbook, not merely as a technical deployment checklist.
Cutover runbook: the time-sequenced plan that defines every step required to move from legacy operations to target operations, including freezes, extracts, validations, interface switches, communications, decision checkpoints, and contingency actions. A good runbook names owners, timing, dependencies, and entry and exit criteria for each step. Without that discipline, teams discover conflicts too late: a final change is approved after the freeze, a document is updated in a source repository that has already been extracted, or a downstream interface is turned on before target validation is complete.
The freeze strategy is central. The business must define when new part creation, document revision, BOM modification, and change approval in legacy systems will stop, what emergency activity remains allowed, and how delta activity during the window will be captured. Freeze window: the controlled period during which source-system changes are restricted so the final migration can occur reliably. The challenge is to make the freeze long enough for a clean cutover and short enough that the business can tolerate it. Many companies use tiered rules: routine changes stop early, while urgent quality corrections remain possible through a tightly governed exception path.
Open work needs special handling. Some in-flight records can move as working objects in the final delta load. Others are better paused and recreated in the new PLM once the system is live. Some legacy approvals need to finish before the freeze because the company does not want partial histories straddling two environments. These transition rules should be defined ahead of time for each major object and workflow state, then tested during rehearsal.
Every serious program should rehearse cutover at least once at full scale. A rehearsal should use real timing assumptions, real migration scripts, real validation steps, and the same governance checkpoints that will exist during go-live. This is how the team learns whether the freeze window is realistic, whether infrastructure throughput is sufficient, and which steps still depend on personal heroics. Rehearsal is also where the program should test contingency logic. Backout plan: the defined method for keeping or restoring business continuity if the target environment cannot meet minimum go-live conditions. Not every program will choose a full rollback, but every program needs a clear threshold for saying the system is not yet safe to open for live work.
A concise cutover readiness checklist usually covers five questions:
- Are source data, mappings, and final delta rules frozen and approved?
- Have critical migration defects been resolved or formally accepted with mitigation?
- Are integrations, access roles, and support teams ready for live operation?
- Have business users been trained on freeze rules, first-day tasks, and issue reporting?
- Is there a named decision forum empowered to authorize go-live or invoke contingency actions?
Communication is often underestimated. Engineers, document controllers, quality reviewers, manufacturing stakeholders, and suppliers need to know what changes during cutover, where to work, what to do if something appears missing, and which transactions are temporarily restricted. The program should therefore publish timing, support channels, and first-day instructions well before the switch occurs.
Hypercare: the intensified stabilization period immediately after go-live during which business users, data stewards, technical teams, and integrators resolve issues rapidly, monitor adoption, and protect critical transactions. Hypercare is not just a help desk. It should function as a command center for product-governance continuity. Missing records, wrong revisions, stuck workflows, role-access issues, CAD integration problems, interface failures, and user misunderstanding all need faster-than-normal response because trust in the new system is still fragile.
The support model should combine business and technical ownership. Technical teams can fix load defects, workflow logic, interface errors, and performance issues. Business stewards need to resolve data meaning, classification, release-state interpretation, and unsafe workarounds that users may attempt. This is why effective hypercare teams include engineering representatives, document-control leads, quality or compliance contacts, and integration support alongside IT. If support is purely technical, many apparent system issues will actually be unresolved governance questions with no one empowered to answer them.
Exit from hypercare should be criteria-based, not calendar-based. The organization should track whether critical transactions are succeeding, whether defect volumes are falling, whether users are staying inside the formal workflows, whether integration failures are under control, and whether cycle times are stabilizing. Only when the business can rely on the new PLM without daily intervention should the program step down into normal support. The real goal is not simply to go live. It is to reach the point where the company trusts the migrated product record enough to operate on it as the new source of truth.
