Understand SAP and AS400 integration and migration, including data access, mapping, validation, common challenges, and practical project best practices.

SAP and AS/400: Data Integration and Migration Explained

An organization may introduce SAP for finance and procurement, while continuing to run manufacturing or warehouse applications on IBM i. Another may replace an established IBM i business application with SAP S/4HANA. Both projects involve SAP and AS400, but their data requirements differ: one needs reliable ongoing exchanges, while the other requires a controlled transfer into a new application.

The challenge extends beyond connecting systems. Teams need to understand what the source records mean, how they relate to SAP business objects, and which application owns each piece of information. A technically successful transfer can still produce incorrect results, if those decisions remain unresolved.

This article explains the relationship between SAP and AS400, the difference between integration and migration, and the practical data work required in each scenario.

What Is the Relationship Between SAP and AS/400?

SAP provides enterprise software for managing business processes, such as finance, procurement, sales, and manufacturing. AS/400, often written as AS400, originally referred to IBM’s integrated business computing system. Today, the term is commonly used informally when discussing IBM i environments, although IBM i is an operating system rather than a current hardware product name. IBM i integrates components, including its database, middleware, and security.

This distinction matters, because AS400 is not a single ERP application. An IBM i environment may host a commercial business application, a custom application, or several applications with different data structures and business rules.

SAP can also run on IBM i within supported product and platform configurations. This means a project may involve either SAP hosted on IBM i or data exchange between SAP and a separate IBM i business application.

Before planning a project, establish which situation applies:

• Separate applications need integration: SAP and a non-SAP IBM i application remain operational and exchange business data.
• A non-SAP application is being replaced: Relevant data from the IBM i application must be prepared and migrated into SAP.
• An existing SAP system is being converted: SAP already runs on IBM i, and the project concerns moving that SAP environment to a different application and platform configuration.

This article focuses on the first two scenarios. Converting an existing SAP system running on IBM i requires a different technical approach from migrating a non-SAP application’s business data.

SAP and AS400: Integration vs. Migration

Integration establishes ongoing data exchanges between applications. Migration transfers an approved data scope into a target application as part of a business transition.

The two approaches can also work together. During a phased SAP rollout, some operations may move to SAP, while others remain in an IBM i application. Temporary interfaces keep the applications connected, until the relevant processes have transitioned.

The table below summarizes the main differences.

The decision should follow the application strategy. If the IBM i application continues supporting a business function, integration may be a long-term requirement. If it is retired, the project needs migration planning and a separate decision about retaining historical information.

Common SAP and AS400 Data Scenarios

The information exchanged or migrated depends on the applications involved, the processes they support, and the responsibilities assigned to each system. Defining these scenarios helps teams establish which records are needed, where updates originate, and how the receiving application uses the data.

The following examples illustrate common project patterns:

• Customer and material data exchange: SAP may own customer and material records, while an IBM i application consumes selected attributes for order processing, manufacturing, or distribution. Mapping must account for identifier differences, required fields, and which application can change each attribute. For example, an SAP material number may need to be linked to an existing item code, so that the IBM i application can use the record, without disrupting its established references.
• Order and fulfillment integration: SAP may pass orders to an IBM i application responsible for fulfillment, with shipment confirmations returned to SAP. The design needs a reliable relationship between source and target document identifiers, including individual order lines. Partial shipments, cancellations, and quantity changes also need agreed handling, so that both applications reflect the same fulfillment progress.
• Inventory information exchange: A warehouse application may provide stock information to SAP for planning or operational visibility. Teams must distinguish a stock snapshot from an inventory movement because these represent different business events and require different processing. The exchange should also preserve relevant context, such as location, batch, unit of measure, and stock status, so that quantities are interpreted correctly.
• Migration of an existing business application: An organization may move customer, supplier, material, inventory, and financial information into SAP S/4HANA. Source records need to be reorganized according to the target business objects and organizational structure. For example, a source customer record may contribute to several parts of an SAP business partner, while inventory quantities require valid material and location assignments before loading.
• Coexistence during a phased rollout: One business unit may move to SAP, while another continues using its IBM i application. Interfaces support cross-system processes, and ownership rules change as subsequent units transition. Teams need to define which application originates each transaction during each phase and when temporary exchanges can be retired.

These scenarios should be defined at the business-object and process level. A requirement to “connect SAP and AS400” is too broad to determine the data scope, direction, frequency, or acceptance criteria.

How SAP and AS400 Data Integration Works

SAP-AS400 integration normally involves source access, extraction, mapping, transformation, validation, and delivery. These stages turn source records into information that the receiving application can use within its business processes. The design starts with defining which data needs to move and in which direction, as well as how quickly it must become available. The implementation then depends on the interfaces available in both applications, their data structures, and the controls needed to confirm successful processing and recovery from failures.

The following activities cover the main considerations for designing and operating a reliable data integration workflow.

Select the appropriate access method

IBM documents client interfaces (e.g., ODBC and JDBC) for accessing Db2 for i data. IBM i also provides integrated web services capabilities that can expose application logic and SQL-based services through APIs.

Possible approaches include:

• Database extraction: Read approved tables or views when their meaning and relationships are understood. Database access provides records, but the extraction design must reproduce any relevant selection or interpretation rules.
• Application APIs: Use available services when data access or updates should pass through application logic. Suitability depends on the operations exposed and their behavior.
• File exchange: Transfer structured exports when applications already provide suitable file interfaces or scheduled exchange meets the business requirement. Define file formats, delivery confirmation, and duplicate-processing controls.

Access methods may differ by direction. Reading source data through a database connection does not imply that directly updating the receiving application’s tables is appropriate.

Map business meaning and transform values

Mapping connects source fields and structures to target requirements. Transformation changes values or structures where the applications represent the same concept differently.

For example, an IBM i application might store a customer’s delivery address within its order records, while the target process requires a separate partner assignment. A source item code may also need a maintained cross-reference to an SAP material number.

These decisions require business and application knowledge. Similar field names alone do not establish that two fields mean the same thing.

Validate and deliver through the target interface

Before delivery, check mandatory attributes, allowed values, reference data, and relationships. Separate exceptions, so that incomplete records can be investigated without losing their processing history.

For SAP, choose an interface supported for the target business object and deployment. The receiving application’s response must then be captured: successful transmission does not necessarily mean that the business record was accepted and posted.

Control recurring execution

Define how new and changed records are identified, when workflows run, and how failures are recovered. Scheduled extraction may suit some processes; others need shorter intervals or event-based execution.

Change detection should reflect the source application’s capabilities. A modification timestamp, for example, is useful only if all relevant changes reliably update it and if deletions are handled separately.

Migrating Data from AS400 Applications to SAP

An AS400-to-SAP migration is a business-data project shaped by the application being replaced. The platform name alone does not reveal the source data model, the customizations involved, or the information needed in SAP. Therefore, planning starts with understanding how the existing application represents business objects and how those objects will be managed in the target system. A customer, material, or order may be spread across several source files and require different structures or organizational assignments in SAP.

A structured process helps turn that understanding into an approved migration scope, documented preparation rules, and measurable acceptance criteria. The steps described below cover the main activities, from defining the data requirements to confirming readiness for business operations in SAP.

Step #1: Define the scope and target requirements

Identify the business processes moving to SAP and the data required to support them. Separate active master data, balances, open transactions, and historical records. Then, define selection criteria for each category. For example, customer selection may depend on outstanding receivables or open orders, as well as recent activity.

Historical data needs an explicit retention decision. Some information may belong in SAP, while other records may remain accessible through an archive or retained application. Moving everything without a business requirement increases preparation and validation effort.

Agree on the scope with business owners and SAP functional specialists. Check dependencies, before finalizing exclusions. For example, an inactive supplier may still be needed for an open purchase order. The resulting scope should specify what is included, what is excluded, and how each decision will be verified.

Step #2: Understand the source data

Revise the relevant tables, files, interfaces, and application documentation. Work with application specialists to identify relationships and rules that are not obvious from the database structure. Business users can help confirm how records are interpreted in daily operations, particularly where screens or reports display calculated values.

A useful starting point is a business-object inventory that connects each required object to its source records, selection rules, owner, and target loading method. Include the keys used to link related records and distinguish between stored values and information derived by application logic.

Check the proposed extraction against representative application screens or reports. If an extracted order total differs from the value users see, investigate whether discounts, status filters, or other calculations explain the difference. Resolving these discrepancies early prevents incorrect assumptions from becoming preparation rules.

Step #3: Prepare and map the data

Profile the source records, resolve quality issues, and define mapping and transformation rules. Typical work includes translating status codes, standardizing units, consolidating duplicate identities, and assigning target organizational values. Document the conditions under which each rule applies, including how missing or ambiguous values are handled.

Mapping should reflect the target business design. A source warehouse code, for example, may require both a plant and a storage location assignment in SAP. Where one source value has several possible target meanings, additional context is needed to choose the correct mapping.

Preserve source identifiers and cross-references throughout preparation. They support investigation, dependent-object mapping, and reconciliation, after SAP assigns target identifiers. When records are consolidated, retain the relationship between every original identifier and the resulting target record, so that related transactions can be mapped consistently.

Step #4: Prepare the target loading approach

Select the loading method for each object according to the SAP deployment, release, and available migration content. Confirm that it supports the required fields and structures, before finalizing the preparation workflow. Any gaps need an agreed solution, such as a supported extension or a separate loading method.

SAP S/4HANA Migration Cockpit supports a staging-table approach in which data is prepared in migration-object structures before it is transferred into the target system. SAP also documents options for populating those staging tables with prepared data. The applicable configuration must be checked for the target environment.

Organize loads around dependencies. Required master data and organizational assignments must be available before dependent transactions can be processed. Define how generated target identifiers and load results will be captured, then make them available to subsequent workflows. This is particularly important when dependent records cannot use the original source identifiers directly.

Step #5: Test and reconcile the results

Test representative records, including exceptions and complex relationships. Cover the full path from source extraction through preparation and loading, rather than testing only the final upload. This helps identify whether an issue originates in source selection, transformation logic, or target processing.

Check both load acceptance and business usability. A record can load successfully, while still carrying an incorrect assignment or converted quantity. Business testing should confirm that migrated data supports the intended activities, such as processing an order or using a material in the appropriate organizational context.

Reconcile according to the object. Inventory may require quantity comparisons by material, location, and unit of measure, while financial data may require approved amount totals by currency and organizational unit. Use totals to assess completeness and record-level checks to investigate differences. Document expected changes, such as lower master-record counts after deduplication, so that they can be distinguished from missing data.

Step #6: Execute cutover and confirm readiness

Define the final extraction point, treatment of changes made after earlier loads, business restrictions, and reconciliation checkpoints. The cutover plan should identify the sequence of activities, responsible owners, and conditions that must be met, before dependent work proceeds.

Rehearse the planned sequence using realistic data volumes and loading dependencies. Measure extraction, preparation, loading, and reconciliation time to establish whether the work fits the available cutover window. Allow time for investigating exceptions and correcting rejected records.

During execution, track what was selected, prepared, accepted, and rejected. Assign responsibility for resolving outstanding issues and approving the final results. Before operations begin in SAP, readiness should be confirmed through agreed reconciliation outcomes and business checks, with any unresolved exceptions explicitly assessed.

Before the final transfer, a data migration readiness checklist can help teams assess whether ownership, data quality, testing, and cutover preparation are sufficiently developed.

Common SAP and AS400 Data Challenges

The most difficult challenges often concern the meaning and completeness of data, rather than its physical transfer. Long-established applications can contain conventions that are familiar to experienced users, but poorly documented for a new project team. These conventions become especially important when information must support different processes and structures in SAP.

The following challenges deserve attention during source analysis, workflow design, and testing.

• Source structures are difficult to interpret: Abbreviated field names, separate files for related information, and multiple record layouts can complicate extraction. A customer or order may be represented across several files, with relationships established through combinations of identifiers, rather than a single obvious key. Teams need to reconstruct the complete business object and understand which records are current, historical, or relevant only under specific conditions. Otherwise, an extract may appear complete, while the information required by the target process is omitted.
• Business rules are embedded in application logic: An application may derive a status, calculate a value, or filter records, when displaying information to users. Therefore, a raw database extract may differ from what appears on an application screen or business report. For example, an order’s outstanding quantity may be calculated from ordered, shipped, and canceled quantities, rather than stored as a separate field. Teams must identify which rules need to be reproduced during preparation and which calculations will be performed by the receiving application.
• Codes and formats differ between applications: Customer numbers, units, dates, and status values may follow different conventions. A technically valid conversion can still change meaning. For example, removing leading zeros may alter an identifier; converting a unit, without adjusting its quantity, produces an incorrect result. Character encoding and field-length differences can also affect names, addresses, and descriptions. These differences require explicit conversion rules and checks for values that cannot be translated unambiguously.
• Target organizational assignments require decisions: A source location code may not correspond directly to an SAP plant or storage location. The same source code may also have different meanings across business units, making a simple lookup insufficient. Organizational mapping must follow the approved target design and use additional context, where necessary. Incorrect assignments can place otherwise valid records in the wrong operational or financial context, so they need business review, as well as technical validation.
• Relationships are lost during preparation: Filtering, deduplicating, or renumbering records can leave transactions without valid parent records. For example, consolidating two customer records requires their related orders and open items to reference the appropriate target identity. Scope rules must account for these dependencies, and cross-references must remain available after identifiers change. Validation should confirm that relationships remain valid in the prepared dataset and after loading, rather than checking individual records alone.
• Changes occur during extraction or transition: Related records may be read at different times, while users continue updating the source. An order header extracted before a change and its lines extracted afterward may form an inconsistent dataset, even though both extracts succeed. The project needs an agreed approach to extraction consistency, subsequent changes, and reconciliation. For recurring integration, this includes recognizing updates and deletions; for migration, it includes controlling changes between earlier loads and the final cutover.

Understanding these issues early helps teams distinguish data defects from unresolved business decisions. A missing mapping may require approval from a process owner, while an incorrectly converted value requires a workflow correction. Assigning each issue to the appropriate owner helps prevent technical workarounds from becoming unintended business rules.

Best Practices for SAP and AS400 Integration and Migration

Reliable data workflows depend on clear rules for ownership, processing, and acceptance. These rules need to remain consistent across source extraction, data preparation, and target processing, particularly when several teams contribute to the same workflow. Establishing such rules early makes results easier to verify and gives teams a clear basis for handling changes and recovering from failures.

The following practices help put these controls into day-to-day project work:

• Assign ownership at the appropriate level: Define who owns each object and individual attributes, where necessary. This prevents competing updates when both applications retain parts of a customer or material record.
• Maintain an approved mapping specification: Record transformations, reference tables, defaults, and reasons for exclusions. Link rules to business decisions, so that changes can be reviewed consistently.
• Design recovery before production execution: Define how interrupted runs resume and how already processed records are recognized. Test a failure after partial delivery to establish whether recovery creates gaps or duplicates.
• Use representative test data: Include unusual characters, inactive records, missing references, multiple organizational assignments, and large documents. These cases reveal issues that a small set of clean records may conceal.
• Agree on reconciliation criteria in advance: Determine which counts, quantities, amounts, and relationships must match. Where consolidation changes record counts, document the expected difference, rather than treating every mismatch as an error.
• Make exceptions actionable: Capture the source identifier, failed rule, target response, and responsible owner. An error log is more useful when it supports correction and controlled reprocessing.
• Match frequency to business needs: Establish the acceptable delay and impact of failure for each exchange. Use those requirements to choose execution frequency and monitoring expectations.

How Migravion Supports SAP and AS/400 Data Workflows

Migravion is an SAP-first data engineering platform for migration, integration, quality, and maintenance workflows across SAP and non-SAP environments. Its workflow capabilities can support the preparation and control needed in projects involving IBM i applications. The appropriate source access method should be established for the specific environment.

Relevant capabilities include:

• SAP connectivity: Migravion provides access to SAP through available interfaces, such as RFC, OData, table reads, and function modules. The appropriate connection depends on the business object, operation, and target environment: extracting reference data and creating or updating business records have different requirements. In workflows involving an IBM i application, this allows teams to select the SAP interface that supports the required exchange, alongside the agreed source access method.
• Visual mapping and transformation: Migravion’s visual workflow designer supports mapping, joins, and transformation rules. Teams can combine source records into complete business objects, translate application-specific codes, and assign target organizational values. For example, customer details from an approved IBM i export can be joined with reference tables to prepare the structures required by the agreed SAP loading method.
• SQL and Python extensions: SQL and Python support allows teams to implement specialized data preparation logic. SQL can support joins, filtering, and calculations, while Python can handle custom parsing or transformations that are difficult to express through standard workflow components. These extensions help incorporate application-specific rules into reusable workflows, reducing the need to perform complex preparation separately for each run.
• Validation and quality checks: Migravion enables teams to evaluate prepared data against defined requirements, before loading or delivery. Checks can identify missing mandatory attributes, unmapped codes, invalid references, and inconsistent relationships between records. Exceptions can be separated for investigation and correction, helping teams resolve preparation issues, before submitting data to the target application.
• Workflow orchestration: Migravion coordinates workflow execution through sequences, schedules, and event-based triggers. Teams can arrange extraction, preparation, validation, and delivery in the required order and automate recurring exchanges. For migration preparation, controlled sequences help manage dependencies — for example, making approved master data mappings available, before preparing related transactions.
• Monitoring and reporting: Logs and run reports provide visibility into processing outcomes and help teams investigate issues. Teams can review preparation errors and target responses when those responses are captured in the workflow, making it easier to locate the stage that requires attention. This visibility supports troubleshooting, controlled reprocessing, and comparison of results across migration test runs or recurring data exchanges.

These capabilities can be combined in a workflow that prepares IBM i application data for migration to SAP. The workflow could consume an approved source export, apply customer and organizational mappings, validate required information, and produce a dataset for the agreed SAP loading method. Reusing the workflow across test runs helps teams apply consistent preparation rules as source data issues are corrected.

Conclusion

SAP and AS400 projects start with an application decision: which processes will remain in the IBM i environment, which will move to SAP, and what information must flow between them. That decision determines whether the project needs ongoing integration, a migration, or temporary coexistence.

Successful execution requires a clear understanding of source data, approved mappings, appropriate interfaces, and measurable acceptance criteria. These foundations allow teams to preserve business meaning, while changing where data is stored and processed.

Migravion helps teams build controlled workflows for preparing, transforming, validating, and moving data across SAP and non-SAP environments. Talk to the Migravion team to discuss the data requirements of your SAP and IBM i integration or migration project.