Velvet Mind – homeDEBook a demo

Insights · SAP Basis

BDLS after a system or client copy: converting logical system names

After every system or client copy from production, the test system contains the wrong logical system name. BDLS converts it – and on large systems this takes hours. This article explains how to prepare the run, where the time goes and how to avoid a subsequent run altogether.

Last updated: 8 October 2026 · By Tobias Foltermann, Founder

What BDLS does

In SAP, a logical system identifies a client of a system as a communication partner, for example for ALE and IDocs. Names following the pattern <SID>CLNT<client> are common, for example PRDCLNT100 for client 100 in the production system PRD. Logical systems are created in BD54; the assignment to the client is made in SCC4.

The name is not only part of the configuration but also of the application data: documents store, for example, which logical system they originate from. Transaction BDLS (conversion of logical system names) replaces an old name with a new one, in all table fields with the domains LOGSYS or EDI_PARNUM.

Why BDLS is needed after every copy

After a copy from production, the QA system contains PRDCLNT100 everywhere, although the client there is called QASCLNT100. Without conversion, documents, IDocs and distribution settings continue to point to production. Distribution, IDoc processing and reports that use the system name then work with incorrect information.

After a client copy, it is sufficient to convert the client-dependent tables. After a system copy, the client-independent tables are added, for every client that remains in use. BDLS is not intended for production systems.

BDLS step by step

  1. Define the names. The old name is the logical system name of the source, the new name that of the target client – following the usual convention, for example PRDCLNT100 and QASCLNT100.
  2. Quiesce the system. Process IDocs, stop background jobs, lock users. No other activities should run in the system during the conversion.
  3. Test run. Start BDLS with the test run option. It determines the affected tables and the number of entries and warns you if the new name already exists in the application tables.
  4. Choose the scope and commit size. After a client copy, the client-dependent tables are sufficient; after a system copy, the client-independent tables are added. Set the number of entries per commit as high as the rollback area of the database allows.
  5. Conversion in the background. Start the real run as a background job. Afterwards, the log shows which tables and fields were converted.
  6. Check communication. Check the assignment of the logical system in SCC4, the partner profiles (WE20), the distribution model (BD64) and the RFC destinations.

BDLS commits table by table. If a run terminates, it can be resumed without starting from scratch. Which other follow-up tasks are needed after a copy is shown in the checklist in the article SAP client copy.

Why BDLS takes so long

BDLS searches every table that contains a field with one of the two domains. These fields are usually not indexed. The database therefore reads large tables in full, in the test run and once again during the conversion.

The runtime therefore grows directly with the data volume. Every full copy brings the complete history with it, and BDLS has to search all of it. On large systems, several hours are normal, and runs lasting several days have also been reported in practice. This time is missing from the downtime window.

Speeding up BDLS

  • Increase the commit size: The default is 1,000,000 entries per commit for Oracle and 100,000 for other databases. Higher values save time as long as the rollback area is sufficient.
  • Exclude empty tables: Tables whose logical system fields are not filled can be excluded, via the selection screen or table BDLSEXZ (SAP Note 932032). Table T000 is always converted.
  • Run in parallel: Several runs for different table ranges shorten the total time, for example with report RBDLS2LS (SAP Note 1547980). Plan enough background processes for this.
  • Treat large tables separately: For very large tables, SAP Note 932032 describes a separate conversion routine.
  • Copy less data: Whatever does not end up in the copy does not have to be searched by BDLS.

Without a subsequent BDLS run

BDLS is necessary because the data is first written to the database and corrected afterwards. The Data Refresh Operator reverses the order and exports the data to files. No BDLS run after the import: DRO knows the fields that contain logical system names and replaces the values during the import, before they are written to the database.

Then there is the time slice: DRO copies only the period needed for testing, plus all dependent objects. This shortens the refresh as a whole.

Copy, then BDLS

  1. ProductionPRDCLNT100
  2. Copy into the databasePRDCLNT100The QA system still carries the production name.
  3. BDLS runScans every table with fields of the domains LOGSYS or EDI_PARNUM, in the test run and again for the conversion.
  4. QA systemQASCLNT100

Data Refresh Operator

  1. ProductionPRDCLNT100
  2. Export to filesDRO knows in advance which fields hold logical system names.
  3. ImportPRDCLNT100 → QASCLNT100Replaces the name before the data is written to the database.
  4. QA systemQASCLNT100no BDLS run
BDLS corrects the names after the data is in the database. DRO replaces them during the import, beforehand. The more data is copied, the longer the BDLS run takes.
3–5×
faster than a full copy, in practice
0
BDLS runs after the import

A practical value: in practice, three to five times faster than a full copy – depending on the system, time frame and exclusions, considerably more is possible. DRO runs on SAP S/4HANA from release 2023.

For system copies, BDLS remains the tool of choice. DRO replaces the client copy, not the system copy. Which method fits when is shown in the comparison of client copy, system copy and time slice. How the entire refresh, including the follow-up tasks, runs automatically is shown in the sample playbook.

Sources

Refresh without a BDLS run?

In a free demo, we show you DRO live using your own use cases – remotely and with no obligation. We discuss where the benefits lie for memory, refresh time and operating costs, and how you can try DRO in your own landscape.

  • Benefits specific to your use cases
  • A live look at time slice, dependency resolution, export and import
  • Answers directly from the team behind DRO

We use your details solely to arrange the appointment. Details in our privacy policy.