SAP LSMW Data Migration: A Safe Operational Workflow

SAP Legacy System Migration Workbench (LSMW) can help move structured legacy data into SAP when the target object and migration method are suitable for the system. Treat each load as a controlled data change: define ownership, validate the source, test the mapping, reconcile the results, and keep evidence of what was processed.

LSMW is especially useful for repeatable loads of master or transactional data in environments where the selected method is available and supported. For an SAP S/4HANA migration, first confirm the approved migration approach for the target release and object. See the SAP master data management overview for how migration fits into broader ownership and control practices.

01Confirm the target object and migration method

Start by identifying the exact business object, organizational scope, and fields to be migrated. Confirm which fields are mandatory, which depend on configuration, and which are maintained by the business after creation. Agree on a record owner for decisions about duplicates, invalid values, and records that should be excluded.

Review the available LSMW object and method choices for the target system and the object. Depending on the system and object, the process may use a standard migration object, a recording, or another available method. A recording follows a transaction flow, so it is sensitive to screen sequence, field behavior, and required actions. Use it only after confirming that the transaction is stable for the intended data and that the process can be tested safely.

For batch input, plan how the session will be created, processed, monitored, and retained as evidence. A session-based run gives operators a way to review processing results and investigate individual records. Do not treat a successful session status as a substitute for checking the created or changed business data.

02Prepare and control the source file

Keep an untouched copy of the source extract and create a separate, controlled load file. Record the extract date, source system, object scope, row count, file owner, and approved changes. Use a consistent file format and encoding, and confirm delimiters, date formats, decimal separators, leading zeros, and blank-value handling before loading.

Clean the source before mapping it. Resolve duplicate candidates, invalid keys, missing mandatory values, and codes that do not exist in the target configuration. Decide explicitly whether blank source values mean “leave unchanged,” “set empty,” or “reject the record”; these meanings must not be inferred during execution. For vendor records, run a duplicate review before creating new master data using the steps in SAP vendor master duplicate checks.

Create a representative test file that includes ordinary records and known edge cases, such as optional fields, long text, special characters, and values that need conversion. Keep test data clearly separated from the production load file.

03Build and verify the mapping

In LSMW, organize the source structure and fields so that each input value has an unambiguous destination. Map values using documented rules, including code conversion, date transformation, defaults, and any required organizational assignments. Keep a mapping specification outside the workbench as well, with a business owner and a technical reviewer identified for each important rule.

Compare the mapping against a small set of records entered or checked through the normal business process. Confirm that key fields, descriptions, organizational data, and dependent values land as intended. When using a recording, test the complete transaction path with representative input. A recording that works for one record can still fail on a different screen path or on an optional-field condition.

Check authorization using the intended operator account before the production window. The account needs the access required to run the migration process and create or change the target data. Resolve missing access through the normal role and approval process, and avoid broad temporary access as a workaround. Include the planned permissions and approver in the run record.

04Run a controlled test and production load

Use a non-production system or an approved test scope first. Process a small sample, review the detailed messages, and verify the created or changed records in the business application. Compare counts and key values against the input file. Include business checks for dependencies, such as required organizational views or related records, rather than relying only on technical completion messages.

Before production, agree on a load window, record volume, stop conditions, business contact, and recovery owner. Take the safeguards required by the system’s change process, and make sure the source file and mapping version are frozen for the run. For large files, divide the load into traceable packages so that progress and failures are easier to isolate.

Process the load using the selected method and monitor the output as it runs. For batch input sessions, review the session processing results and capture counts for processed, successful, and failed records. Preserve the input file, mapping version, run time, operator, session or run reference, and outcome summary in the migration evidence.

05Reconcile results and handle failures

After processing, reconcile input and target results by key and count. Check the most important business fields and any fields that drive downstream processes. Have the data owner approve the reconciliation before closing the load. Apply the organization’s master data quality checks to verify completeness, consistency, and duplicate risk.

Classify errors before retrying. Common causes include invalid source values, missing required fields, incorrect conversion rules, configuration gaps, authorization failures, and unexpected transaction behavior. Correct the underlying cause, then test the correction with a small subset. Reprocess only the records that are confirmed not to have been created or changed successfully; first check their target state to prevent duplicate creation or unintended overwrites.

If a load changes data incorrectly, stop further processing and follow the approved correction or recovery procedure with the business owner. Do not assume that rerunning the original file will reverse prior changes. Record the affected keys, impact, decision, and corrective action.

06Keep the migration repeatable and auditable

Maintain a runbook containing the object scope, selected method, mapping rules, file format, test evidence, authorization approvals, run steps, reconciliation checks, and recovery contacts. Store source files and result logs according to the organization’s data-retention and access rules. Restrict access to files that contain personal, financial, or commercially sensitive information.

For recurring loads, use change control for mapping or recording updates and rerun regression tests after a change. Track rejected records to resolution rather than silently dropping them. Once business owners approve the data and reconciliation, close the run with a clear record of totals, exceptions, and outstanding follow-up.

LSMW works best as a governed operational process, not as a shortcut around data ownership or validation. A carefully scoped object, tested mapping, controlled batch, and evidence-based reconciliation make migration outcomes easier to explain and safer to repeat.