Mapping custom fields vs standard fields in requirements management during data migration

PLM Windchill
, , , , , , ,
1

I’m planning a requirements data migration to Windchill 11.1 M030 and facing decisions about field mapping strategies. Our legacy requirements tool has extensive custom fields that don’t directly correspond to Windchill’s standard requirement attributes.

The challenge: Should we map everything to custom attributes in Windchill to preserve exact field correspondence, or normalize our data to fit Windchill’s standard fields even if it means losing some granularity?

For example, our legacy system has separate fields for “Business Justification,” “Technical Rationale,” and “Regulatory Driver.” Windchill has a standard “Description” field and supports custom attributes. Mapping each to a custom attribute maintains the distinction but creates complexity. Combining them into the description field simplifies the model but loses structured data.

Another concern is traceability link mapping - our legacy system has 15 different link types (derives-from, refines, conflicts-with, etc.), while Windchill has fewer standard link types. How are others handling field normalization versus custom attribute preservation in requirements migrations?

system 2

Field Mapping Strategy: Windchill 11.1 M030 Requirements Migration

Pre-Upgrade Checks

Before committing to a mapping strategy, validate these constraints in your target 11.1 M030 environment:

  • Attribute capacity limits: Confirm your Windchill type definition doesn’t breach the underlying Oracle column limits for custom IBA (Instance-Based Attribute) proliferation. Excessive IBAs degrade query performance on WTRequirement subtypes.
  • RMF module structure: Verify whether you’re migrating into Windchill RV&S (formerly Integrity) integration or native Windchill Requirements Management. The attribute model differs significantly between them — verify in your version.
  • Link type registry: Pull the existing WTLinkService registered link types via the type manager (typemanager in the Method Server console) to get your actual baseline before assuming defaults.
  • Source data quality: Profile null rates and cardinality on every legacy field. Fields with >70% null population are low-value candidates for dedicated custom attributes.
  • Type hierarchy: Decide upfront if requirements will share a single WTRequirement subtype or use multiple subtypes segmented by requirement category. This affects where custom attributes live and how traceability link constraints are enforced.

Migration Sequence

  1. Classify legacy fields into three buckets: direct map to standard attribute, promote to custom IBA, or denormalize into a structured text block.

  2. For your three-field example (“Business Justification,” “Technical Rationale,” “Regulatory Driver”): create three discrete IBAs on your WTRequirement subtype. Do not collapse into description. Structured data destroyed during migration cannot be recovered without re-engaging the source system. The added attribute complexity is a one-time cost; the data loss is permanent.

  3. Define a custom attribute naming convention (legacy_<fieldname> prefix) to distinguish migrated fields from natively created ones — critical for post-migration audits.

  4. Link type normalization: Map your 15 link types against Windchill’s standard set (satisfies, derives, refines, verifies, traces). For types with no equivalent (e.g., conflicts-with), create custom link descriptors using the Windchill Link Type customization framework rather than collapsing semantically distinct relationships. conflicts-with mapped to traces silently corrupts your traceability matrix.

  5. Build a mapping specification document as a formal artifact — not a spreadsheet footnote. This becomes the reconciliation reference during UAT.

  6. Run a pilot migration on a representative 5–10% sample using Windchill Bulk Migration Utility or your ETL tooling (LoadFromFile/xconfmanworker paths), validate attribute population and link traversal via wt.fc.QuerySpec or the Requirements Explorer UI.

  7. Execute full migration, freeze the source system, validate record counts and link integrity end-to-end.

  8. Retire legacy field mappings from the type definition only after a formal sign-off period — keep IBAs dormant rather than deleting them immediately.

Rollback Procedure

  • Rollback is only viable before source system decommission. Maintain a live snapshot of the source database through at least one full sprint of post-migration validation.
  • If migration-phase errors occur: restore Windchill to the pre-migration type snapshot (export type definitions via Windchill Type and Attribute Manager before step 1), truncate migrated objects, and re-run from step 6.
  • Custom link descriptors added to the registry must be explicitly removed via type manager — they are not rolled back by object deletion.
  • Do not drop IBAs during rollback; mark them inactive to preserve schema history.

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.

3

This is a classic migration dilemma. I generally lean toward using Windchill’s standard fields where possible and only creating custom attributes for truly unique data that’s actively used. In your example, if those three justification fields are rarely searched or reported on separately, combining them into description with clear section headers makes sense. It reduces ongoing maintenance of custom attributes and simplifies the data model for new users.

4

I disagree with oversimplifying. If your organization has established processes around those distinct fields, combining them into description loses that structure and breaks existing workflows. Custom attribute support in Windchill is robust - use it. The tradeoff is configuration complexity, but that’s a one-time cost versus ongoing process disruption. For traceability links, I’d map your 15 types to Windchill’s standard types using a mapping table and document the translation in your migration guide.

5

Those are valid opposing viewpoints. The usage question is key - I need to analyze how frequently each custom field is actually used in searches, reports, and workflows. If business justification is searched independently 100 times per month, it should be a custom attribute. If it’s just read as part of the overall requirement context, description field makes sense.

6

Don’t forget the reporting implications. Custom attributes require custom report templates and potentially custom searches. Standard fields work with out-of-box reports and queries. I’d do a cost-benefit analysis: What’s the business value of maintaining field granularity versus the ongoing cost of custom attribute maintenance, training, and reporting configuration? Also consider future Windchill upgrades - custom attributes add complexity to upgrade testing.

7

For traceability link mapping, we faced the same challenge with multiple link types. We analyzed link usage patterns and found that 80% of links used only 5 of our 15 types. We mapped those 5 to Windchill standard link types and consolidated the remaining 10 into 2 generic custom link types (“Related-To” and “Impacts”). We documented the original link type in the link description field so we didn’t lose that information completely. This gave us a good balance between preserving semantics and simplifying the model.

8

After managing several requirements migrations, I’ve developed a field normalization framework that balances these concerns:

Field Mapping Decision Matrix:

Use this criteria to decide custom attribute vs standard field:

  1. Usage Frequency: If field is used in >20% of requirements, consider custom attribute
  2. Search Dependency: If field is searched/filtered independently, needs to be custom attribute
  3. Workflow Integration: If field drives state transitions or approvals, must be custom attribute
  4. Reporting Requirements: If field appears in executive dashboards or compliance reports, custom attribute preferred
  5. Regulatory Traceability: If field is required for audit trails, use custom attribute for explicit tracking

Custom Attribute Support - When to Use:

Create custom attributes for:

  • Fields with controlled vocabularies (picklists) that drive business logic
  • Numeric fields used in calculations or threshold validations
  • Date fields tracked for compliance or milestone reporting
  • Fields that need independent access control or visibility rules

For your specific example (Business Justification, Technical Rationale, Regulatory Driver):

  • If these drive approval routing or compliance reporting → Custom attributes
  • If they’re informational context → Combine into structured description with XML tags for potential future extraction

Standard Field Normalization - Best Practices:

Map to standard fields when:

  • Legacy field semantics align with Windchill standard field purpose
  • Field usage is primarily display/read rather than search/filter
  • Data type matches (text to text, date to date)
  • No complex validation rules on the legacy field

Traceability Link Mapping Strategy:

For your 15 link types, apply this three-tier approach:

Tier 1: Direct Mapping (High-Value Links) Map your most-used 4-5 link types to Windchill standard types:

  • derives-from → Derived From
  • refines → Refines
  • depends-on → Depends On
  • validates → Verified By

Tier 2: Consolidated Custom Links (Medium-Value) Group similar semantics into 2-3 custom link types:

  • conflicts-with, incompatible-with → “Conflicts” custom link type
  • impacts, affects, influences → “Impacts” custom link type

Tier 3: Metadata Preservation (Low-Value) For rarely-used link types, use a generic “Related” link and store original type in link description:


Link Type: Related
Description: [LEGACY: enhances] Original enhancement relationship from legacy system

Field Normalization Strategies:

  1. Structured Text Approach: Combine related fields into description using XML or markdown structure:
<description>
  <businessJustification>Cost reduction initiative</businessJustification>
  <technicalRationale>Legacy system EOL</technicalRationale>
  <regulatoryDriver>FDA 21 CFR Part 11 compliance</regulatoryDriver>
</description>

This preserves structure for potential future extraction while using standard fields.

  1. Hybrid Approach: Use standard fields for high-frequency attributes, custom attributes for specialized fields:
  • Standard: Name, Description, Priority, Status, Owner
  • Custom: RegulatoryDriver (picklist), ComplianceCategory (picklist), ValidationStatus (enum)
  1. Metadata Table Approach: For extensive custom data, create a separate metadata table linked to requirements:
  • Core requirement uses standard fields
  • Extended attributes stored in related metadata object
  • Maintains clean requirement model while preserving all legacy data

Analysis Before Migration:

Run these queries on your legacy data:

  1. Field usage frequency (% of requirements with non-null values)
  2. Search/filter frequency (from system logs)
  3. Report dependency analysis (which fields appear in active reports)
  4. Workflow integration (which fields trigger actions)

This data-driven approach helps justify custom attribute decisions with objective metrics.

Potential Data Loss Mitigation:

When normalizing fields, implement these safeguards:

  • Export complete legacy data snapshot before migration
  • Document all field mapping decisions in a traceability matrix
  • Store original field values in a migration metadata custom attribute
  • Create a post-migration validation report comparing source vs target data

For your specific scenario, I’d recommend:

  • Keep Regulatory Driver as custom attribute (likely compliance reporting requirement)
  • Combine Business Justification and Technical Rationale into Description with structured format
  • Map your top 5 link types directly, consolidate others into 2-3 custom types
  • Preserve original link type in description field for audit purposes

This balances system simplicity with data preservation and supports both current workflows and future flexibility.