A practical guide to SAP PLM migration from ECC to S/4HANA — learn best practices based on a large-scale engineering data migration project.

Migrating SAP PLM Data from ECC to S/4HANA: Handling DIRs, Originals, and Delta Loads at Scale

Migrating from SAP ECC to S/4HANA is a major transformation initiative. Yet when the scope extends beyond transactional data into SAP PLM objects — particularly Document Info Records (DIRs), associated originals, document structures, and Change Masters — the complexity shifts to an entirely different level. 

PLM migration is not transactional migration. It is relational, revision-driven, file-dependent, and governed by engineering logic that has often evolved over decades. In engineering-centric organizations, document integrity equals operational integrity. Losing version history, breaking document structures, or misaligning revision logic directly impacts traceability, compliance, and product lifecycle continuity.

This article explores what it truly takes to migrate SAP PLM data at scale and why structured orchestration, rather than simple extraction tooling, determines success.

Why SAP PLM Migration Is Fundamentally Different

SAP PLM migration is fundamentally different from transactional data migration because it transfers not only records, but an organization’s engineering control framework. PLM objects collectively define product configuration, revision logic, and compliance traceability. Migrating them requires preserving engineering meaning, rather than merely data fields.

Core SAP PLM objects include:

• DIRs (Document Info Records): DIRs are lifecycle-controlled engineering objects that encapsulate: document type logic, version and revision identifiers, status control, effectivity data, classification attributes, and cross-object relationships. In many SAP landscapes, DIRs are tightly linked to materials, BOMs, equipment, and quality records. When migrating DIRs, it is imperative to preserve revision sequencing, release states, object link consistency, and historical traceability. If revision lineage is disrupted, the documented product definition may no longer reflect reality.
• Original files: Originals are physical engineering deliverables that include CAD files, drawings, specifications, simulation outputs, validation reports. These files are version-bound and lifecycle-controlled. They often reside in distributed repositories and may be reused across multiple assemblies or products. An original without its correct metadata context is misclassified intellectual property. To ensure operational continuity for engineering teams, PLM migration must preserve the exact alignment between file content, revision level, and lifecycle status.
• DIR structures: Document structures define hierarchical relationships between technical documents (e.g., an assembly drawing referencing subassemblies or a master specification referencing subordinate technical instructions). These structures reflect engineering logic, representing how documentation components depend on one another. If structural relationships are partially migrated, flattened, or reordered, the meaning of documentation changes. Maintaining structural coherence is therefore essential to preserving engineering intent.
• Change Masters: Change Masters formalize engineering governance. They document who initiated a change, why it occurred, which objects were affected, and when the change became effective. In regulated industries, Change Masters are part of audit and compliance documentation. They establish revision accountability and chronological traceability. Migrating Change Masters requires preserving historical links between revisions, affected documents, and approval logic. Without this continuity, the engineering audit trail is incomplete.

These objects do not operate independently. Together, they form an interconnected governance ecosystem that defines how products are documented, revised, approved, and released. Understanding this ecosystem explains why SAP PLM migration introduces characteristics that are not present in transactional migration projects.

The following characteristics distinguish SAP PLM migration from other SAP data migration streams:

• Revision-driven data model: PLM data is inherently versioned. Documents exist across multiple revisions, each governed by lifecycle status that is often tied to formal change control. Migration must preserve revision order, validity relationships, and historical lineage. Unlike transactional domains, where current-state accuracy is often sufficient, PLM migration must maintain engineering chronology in full.
• Structural interdependencies across objects: PLM objects are multi-layered and relational. Documents link to other documents, materials, equipment, and change records. A modification to one object may affect multiple related structures. Migration must therefore preserve relational integrity across these layers. A single broken dependency can alter how product documentation is interpreted downstream.
• Binary and metadata coupling: PLM migration involves both structured metadata and binary engineering assets. Metadata defines the document’s identity, revision, and lifecycle. The binary file contains the technical substance. These two layers must remain perfectly synchronized. Misalignment results in incorrect revision access, operational confusion, or compliance exposure.
• Lifecycle governance sensitivity: SAP PLM behavior is heavily influenced by configuration governing revision control, status transitions, and change processes. Migration must preserve both data structure and lifecycle semantics (how objects behave over time). Even subtle inconsistencies in lifecycle interpretation can distort document validity in the target system.
• Compliance and audit exposure: In industries, such as manufacturing, aerospace, and medical devices, PLM data underpins regulatory compliance. Revision history, change lineage, and approval documentation must remain intact. Therefore, PLM migration carries higher audit sensitivity than typical master or transactional data migration.
• Engineering continuity requirements: Engineering operations depend on uninterrupted access to valid document revisions. During and after migration, production, maintenance, quality, and service processes must reference correct technical documentation, without disruption. PLM migration must therefore ensure continuity of engineering usage — not just technical data availability.
• Product definition integrity: Ultimately, PLM data defines the product itself. It determines which drawing governs manufacturing, which specification defines compliance, and which revision applies to a configuration. Transactional data records business activity; PLM data defines engineering truth. Preserving that truth is the core objective of PLM migration.

SAP PLM migration is therefore not a conventional data transfer exercise. It is the controlled preservation of engineering governance, structural logic, and revision integrity.

The Core Technical Challenges in SAP PLM Migration

Migrating SAP PLM data is rarely a straightforward technical exercise. Even when the data volumes appear manageable, the underlying complexity lies in the relationships, lifecycle logic, and engineering dependencies embedded within the data.

Unlike transactional migration streams, PLM migration must preserve the integrity of engineering documentation and the governance structures that control it. This introduces a distinct set of technical challenges that require careful architectural planning and disciplined execution.

Below are the most critical challenges organizations encounter when migrating PLM data from SAP ECC to SAP S/4HANA.

High-volume metadata extraction across interconnected tables

PLM data is distributed across numerous SAP tables that represent documents, versions, object links, classifications, and change records.

Migrating even a moderately sized PLM landscape may require extracting data from dozens of related tables. These tables contain different layers of information:

• Document master records
• Language-dependent descriptions
• Document structures and object links
• Classification and characteristic values
• Change control relationships
• Status and lifecycle metadata

While individual tables may not be large compared to transactional datasets, their interdependencies are significant. Extracting data without preserving these relationships introduces risks during downstream reconstruction of the document model.

Another important consideration is consistency across extraction windows. Because PLM data often remains active during migration projects, the extraction strategy must ensure that object relationships remain synchronized across all tables.

In practice, this requires a carefully orchestrated extraction approach that captures a consistent view of the PLM dataset.

Complex transformation of engineering data

PLM migration almost always requires transformation before loading data into the target system.

Over time, engineering landscapes accumulate historical artifacts, such as:

• Obsolete document types
• Redundant revisions
• Legacy naming conventions
• Inconsistent classification usage
• Historical change records that no longer apply

Migrating this data as it stands can introduce unnecessary complexity into the target system. As a result, organizations frequently perform data cleansing and restructuring during migration.

Typical transformation activities may include:

• Removing obsolete document types or inactive revisions
• Aligning document numbering conventions
• Adjusting revision identifiers
• Consolidating redundant structures
• Normalizing classification values

However, these transformations must be applied carefully. Because PLM objects are interconnected, modifying one object often requires recalculating relationships across multiple datasets. For example, removing an obsolete revision may require updating document structures, object links, and change references to maintain consistency.

Therefore, PLM transformation requires a controlled staging approach where dependencies can be analyzed and reconciled before load.

Managing external original files

A major complexity in PLM migration arises from the handling of original engineering files.

In many SAP ECC environments, original files are not stored directly within the SAP database. Instead, they may reside in:

• SAP Content Server repositories
• Third-party document management systems
• Legacy file storage platforms
• Network-based engineering repositories

These files must remain correctly associated with their corresponding DIRs and revision levels.

This introduces a dual-layer migration challenge: migration of document metadata vs. migration of binary engineering content. Both layers must remain synchronized throughout the migration process. For example, if a document revision is renumbered or filtered during transformation, the associated original file must reflect the same revision relationship. Failure to maintain this alignment can lead to incorrect document attachments or missing engineering content.

Handling external originals requires careful coordination between metadata migration and file migration processes.

Preserving document structures and object relationships

Engineering documentation often exists within hierarchical structures. A single product assembly may reference multiple drawings, supporting specifications, quality documentation, and regulatory compliance documents. These relationships are captured in document structures and object link tables.

During migration, these structures must be preserved exactly as they exist in the source system. Even small inconsistencies can disrupt how documents are interpreted by engineering teams. For example, if a structural reference between documents is lost or misaligned, users may no longer be able to correctly navigate documentation hierarchies.

Maintaining these relationships requires careful validation of:

• Parent-child document structures
• Object links to materials, equipment, or BOMs
• Cross-document dependencies

Structural integrity is crucial to ensuring that the engineering knowledge encoded in the PLM system remains intact.

Handling change governance and revision logic

Engineering documentation evolves through controlled change processes. Change Masters govern how revisions are created, approved, and released. These objects link together document versions, effectivity dates, and approval workflows. Migrating these records is essential for preserving the historical context of engineering decisions.

However, revision logic can be complex. Documents may have:

• Multiple revision levels
• Version counters within revisions
• Status transitions tied to lifecycle workflows
• Effectivity conditions tied to product configurations

During migration, these elements must remain synchronized. If revision sequencing or change references are disrupted, the resulting dataset may no longer reflect the true evolution of the product design. Ensuring revision continuity is therefore one of the most critical aspects of PLM migration.

Managing data consistency during active system usage

PLM systems often remain active during migration projects. Engineering teams continue to create new documents, update existing revisions, approve engineering changes, and upload new original files.

This ongoing activity introduces a challenge: the migration must capture both the initial dataset and any changes that occur between extraction and system cutover. Without an effective synchronization strategy, recent engineering updates may be lost or partially migrated.

PLM data consistency during active system usage requires careful coordination between extraction, validation, and final migration phases.

Configuration sensitivity in the target system

SAP PLM behavior is highly influenced by configuration settings in the target system.

These configurations control aspects such as:

• Document types
• Revision level management
• Status networks
• Classification behavior
• Change control integration

If these settings differ between source and target environments, document behavior after migration may not match expectations. For example, a document revision that was valid in the source system may behave differently if revision control is configured differently in the target environment.

Ensuring configuration alignment is essential to preserving document lifecycle logic.

Iterative validation and load stabilization

PLM migration rarely succeeds in a single execution cycle. Because of the complexity of object relationships and lifecycle behavior, multiple validation cycles are typically required to refine the migration approach.

These cycles allow teams to:

• Identify structural inconsistencies
• Validate revision sequencing
• Verify document accessibility
• Confirm that engineering workflows function as expected

Each iteration helps refine transformation rules, structural mapping, and validation procedures.

This iterative stabilization process is critical to ensuring that the final migration preserves both technical data integrity and operational usability.

Real-World Example: SAP ECC to S/4HANA PLM Migration at Scale

Large-scale PLM migrations are often discussed in theoretical terms, but their true complexity only becomes clear in real projects where engineering data, revision history, and external document repositories must be moved without disrupting operational continuity.

The following case illustrates how a global manufacturer successfully migrated its SAP PLM landscape from SAP ECC to SAP S/4HANA as part of a broader enterprise transformation initiative.

Customer Overview

The customer is a global industrial equipment manufacturer with operations across multiple regions, employing several thousand employees worldwide. Its engineering organization relies heavily on SAP PLM to manage product documentation, including technical drawings, design specifications, and controlled engineering revisions.

Over years of product development, the company accumulated a large PLM dataset that served as the backbone of product definition, engineering collaboration, and compliance documentation.

As part of a global SAP S/4HANA Lift & Shift transformation program, the organization needed to migrate this PLM landscape, while preserving engineering traceability and minimizing disruption to ongoing operations.

Challenge

The PLM migration scope was significant and included multiple types of engineering objects.

The dataset spanned:

• 800,000+ Document Info Records (DIRs)
• 2.5 million associated original files
• 100,000+ Change Masters
• 450,000+ DIR structures

These objects formed a highly interconnected engineering documentation environment. Their migration required the preservation of:

• Revision history
• Document hierarchies
• Change control relationships
• File-to-metadata consistency

Several factors added complexity to the migration:

• External engineering file repository: Original document files were not stored directly within SAP. Instead, they were maintained in an external Drawing Locator repository. This meant that the migration required coordinated handling of both SAP metadata and external binary content. Ensuring correct alignment between metadata and files was critical to maintaining engineering document integrity.
• Ongoing engineering activity during migration: The SAP ECC system remained active for engineering teams during the migration preparation phase. New document revisions and engineering changes continued to be created. As a result, the migration architecture had to accommodate delta updates to ensure that late-stage changes were captured before cutover.
• Complex document dependencies: PLM data contained extensive dependencies across document structures and object links. Certain revisions needed to be adjusted or removed entirely to align with the target system’s governance model. This required a carefully controlled transformation process before loading data into SAP S/4HANA.

Solution

To address these challenges, the project followed a structured ETL-based migration architecture.

Parallel infrastructure setup

Multiple virtual machines were deployed to support parallel extraction and load activities. This infrastructure allowed the migration team to process large volumes of metadata and engineering files efficiently, while maintaining control over transformation logic.

Metadata extraction

SAP PLM metadata was extracted from approximately 30 SAP tables representing documents, structures, change records, and related dependencies.

A high-performance extraction approach was used to transfer the metadata from SAP ECC into a staging environment. This allowed the entire dataset to be captured within a short time frame, ensuring a consistent baseline for further transformation.

Structured staging and transformation

SQL Server Management Studio (SSMS) served as the staging environment where extracted metadata was transformed and prepared for migration.

Within this staging layer, the project team applied multiple transformation rules to align the legacy dataset with the S/4HANA target model.

Examples of these transformations included:

• Filtering out obsolete document types
• Adjusting DIR versions based on revision logic
• Removing redundant document revisions
• Resolving dependencies across document structures and object links

This transformation stage ensured that only relevant and structurally consistent data would be loaded into the new system.

External file processing

Since original engineering files were stored outside SAP, a dedicated processing workflow was implemented.

Custom Python scripts were used to:

• Extract original files from the external repository
• Clean and standardize file structures
• Allocate files to the appropriate document revisions
• Prepare binaries for upload into the S/4HANA environment

Handling external content separately from metadata ensured that both layers could be validated independently before final load.

Delta synchronization

To address ongoing engineering activity in the source system, a delta synchronization mechanism was implemented.

Two approaches were used, depending on object type:

• Direct extraction using “Changed On” timestamps in SAP tables
• Custom Python logic that read SAP Change Documents and identified updated records

This dual approach ensured that any engineering updates created during the migration window were included in the final dataset.

S/4HANA load process

Loading PLM objects into SAP S/4HANA required careful orchestration.

For DIRs, the migration team leveraged BAPI_DOCUMENT_LOAD as the primary load interface. This approach allowed multiple elements to be loaded in a single operation, including document metadata, classification attributes, original files, and status information.

However, the BAPI required extensive preparation and testing. Certain system configuration parameters (e.g., revision level assignments) could significantly influence how documents behaved during the load process.

Because of these dependencies, the migration team conducted numerous validation cycles to stabilize the load methodology before executing the final production migration.

During preparation of load datasets, DataLark’s automapping functionality was used to automatically generate field mappings between ECC source structures and S/4HANA target objects.

Furthermore, DataLark significantly accelerated SAP data loading by leveraging direct SQL inserts and parallel execution streams, allowing large volumes of data to be processed much faster than traditional sequential loading approaches.

Additional challenges encountered

Like most large-scale migrations, the project encountered several operational challenges along the way, for example:

• Certain technical tables that could not be reliably loaded using standard BAPIs and required alternative loading approaches
• Scope adjustments introduced close to the go-live date
• Infrastructure setup challenges related to virtual machines, security permissions, and software configuration

In addition, the team performed hundreds of iterative load runs during testing. Each cycle helped refine transformation rules, validate document relationships, and ensure consistent load behavior.

This iterative validation process was critical to ensuring stability during the final production migration.

Results

Despite the complexity of the dataset and the technical challenges involved, the project successfully migrated the entire targeted PLM environment.

Key outcomes included:

• Migration of 800,000+ DIRs
• Transfer of 2.5 million associated original engineering files
• Migration of 100,000+ Change Masters
• Preservation of 450,000+ document structure relationships

Additionally, the migration process enabled the organization to remove redundant and obsolete data before loading it into the S/4HANA environment, improving the quality of the engineering dataset.

The final migration was completed successfully in alignment with the overall S/4HANA program timeline.

This project demonstrates that large-scale SAP PLM migration requires more than data extraction and loading. It demands a structured migration architecture capable of handling document dependencies, revision history, external engineering files, and ongoing operational activity.

With a disciplined approach that combines structured staging, controlled transformation, coordinated file handling, and iterative validation, even highly complex PLM landscapes can be successfully migrated to SAP S/4HANA while preserving engineering traceability and operational continuity.

Best Practices for Large-Scale PLM Migration

Large-scale PLM migrations reveal patterns that are not always obvious during project planning. Engineering documentation ecosystems evolve over many years, accumulating structural dependencies, revision histories, and legacy conventions that must be carefully managed during system transformation.

Based on practical migration experience, several best practices consistently emerge as critical success factors for SAP PLM migration initiatives.

Extract efficiently, but validate context

Fast extraction of PLM metadata is essential for maintaining a consistent migration baseline, particularly when engineering activity continues in the source system. However, speed alone is not sufficient.

Extracted datasets must be validated to ensure that document relationships, revision hierarchies, and change references remain consistent across all related tables. Because PLM objects form interconnected governance structures, incomplete or inconsistent extraction can introduce structural gaps that become difficult to reconcile later in the migration process.

A well-designed extraction strategy balances performance with structural validation.

Transform engineering data before loading

Legacy engineering environments often contain outdated document types, redundant revisions, or historical artifacts that no longer reflect the active product definition.

Migrating this data without preparation can introduce unnecessary complexity into the target system.

A controlled transformation phase allows organizations to:

• Remove obsolete documents or revisions
• Align naming and numbering conventions
• Normalize classification attributes
• Simplify document structures

By resolving these issues before the load stage, the target S/4HANA system receives a cleaner and more maintainable engineering dataset.

Treat metadata and engineering files as separate but coordinated streams

PLM migration involves two fundamentally different types of assets: structured metadata and binary engineering files.

These layers must remain synchronized, but they often require different handling approaches. Metadata can be transformed, filtered, or reorganized during migration preparation, while original files must remain correctly associated with the corresponding document revisions.

Treating these layers as separate migration streams — while maintaining strict alignment between them — reduces the risk of incorrect document attachments or missing engineering files.

Design the delta strategy early

Engineering systems rarely remain static during migration preparation. Engineers continue to create documents, revise drawings, and approve engineering changes while migration work is underway. Without a structured delta strategy, these updates may be lost between initial extraction and system cutover.

Planning delta synchronization early in the migration architecture ensures that late-stage document updates are captured and integrated into the final dataset, preserving revision continuity and operational accuracy.

Align lifecycle configuration between systems

SAP PLM behavior is strongly influenced by configuration settings that govern revision control, status transitions, and document lifecycle logic. Before migration begins, these configurations should be carefully aligned between source and target environments.

Even subtle differences in lifecycle configuration can affect how documents behave after migration. Ensuring configuration consistency helps preserve the intended lifecycle semantics of engineering documentation.

Plan for iterative migration validation

PLM migrations are rarely completed in a single execution cycle. Because of the complex relationships between documents, revisions, and change records, multiple validation iterations are typically required.

These cycles allow migration teams to verify:

• Revision continuity
• Document structure integrity
• Accessibility of original files
• Consistency of engineering relationships

Each iteration improves the accuracy of transformation rules and load procedures, ultimately ensuring a stable final migration.

Maintain focus on engineering integrity

Throughout the migration process, technical execution must remain aligned with the ultimate goal: preserving the integrity of engineering documentation.

Successful PLM migration is not defined solely by data transfer metrics. It is defined by the ability of engineers, manufacturing teams, and quality organizations to continue using the documentation environment without disruption.

When engineering traceability, revision history, and document accessibility remain intact after migration, the transformation has achieved its objective.

Conclusion

SAP PLM migration from ECC to S/4HANA represents one of the most complex aspects of enterprise system transformation. Unlike transactional data migration, PLM migration must preserve engineering governance, document structures, revision history, and the relationships that define product configuration.

Large PLM environments introduce a unique combination of challenges: highly interconnected metadata, external engineering files, evolving document revisions, and strict lifecycle control requirements. Successfully navigating these complexities requires more than extraction tools or simple data transfer scripts. It demands a structured migration architecture capable of managing dependencies, coordinating metadata and binary assets, and validating engineering continuity throughout the process.

Organizations that approach PLM migration with architectural discipline — combining controlled extraction, structured transformation, coordinated file handling, and iterative validation — can successfully transition even the largest engineering documentation landscapes to SAP S/4HANA, while preserving the integrity of product definition and engineering traceability.

This is where a dedicated migration orchestration platform becomes essential.

DataLark provides an SAP-centric data management and migration framework designed to support complex transformation programs, including large-scale PLM migrations. DataLark helps organizations manage the full lifecycle of PLM migration projects with transparency and precision by enabling high-volume metadata extraction, structured staging and transformation, coordinated handling of engineering files, and controlled load orchestration.

Contact the DataLark team to learn how structured SAP data orchestration can support your PLM migration and broader S/4HANA transformation initiatives.