SAP SLT Replication Step-By-Step (Guide)

10. October 2022

Although it may not sound so at first, the SLT replication procedure can be quite tricky to get on with. However, that’s what we are going to decipher in this article. So, let’s not make any further ado and get started with our guide right away!

Installation Option For An ABAP And A Non-ABAP Source

When it comes to performing the SLT replication procedure, you can do it through more than one source. Here’s what you need to know about them.

For ABAP Source System

In this case, you can perform the installation procedure through two different options. Please keep reading to learn more about this aspect –

Option – A: The Replication Server Is An Entirely Separate System.

To begin with, you can establish the connection between the SAP Source and the SAP SLT as an RFC connection. If you are not comfortable with that, you may also do the same by using the DB connecting procedure. Once you are done with the table replication procedure, you might try creating a logging table within the source system. Conversely, the read module is going to be created automatically within the SAP Source System.

Option – B: The Replication Server Has Been Installed Within The Source.

In this case, the SAP LT replication server has to be installed at the beginning of the process. Once it’s done, you’ll need to integrate the required SAP NetWeaver and SAP kernel with the same too. The system architecture, then, must be simplified into a two-tier system.

For A Non-ABAP Source System

In this aspect, your job will be a little more intricate and complicated if you haven’t done this task before. Here’s what you have to do here.

  • In the beginning, you will need to install the SAP LT server into a separate structure. And, once you’re done, you’ll have to only create the read modules in this case. And the connection between the non-ABAP source to the SAP LT server will be prompted or established through a database connection.
  • In the second case, you should begin by checking if your non-ABAP source system is fulfilling all the usage-related prerequisites or not. After all, database connectivity from the non-ABAP system to the SAP LT server will be required in this aspect. Thus if the connection hasn’t been secured, the replication procedure might get crashed.

The Steps Of SLT Replication

Usually, the SLT replication procedure is completed in five minor yet important steps. It may include the following ones for you –

Step – 1: Installing The Replication Server.

The SAP LT replication server will be shipped in a DMIS-based add-on call. So, if you want to begin the replication procedure, you’ll need to install the server in your system first. The installation should be done within your ABAP source system and in the server too.

Note: If the source system is based on an on-premise SAP S/4HANA structure, then there’s no need to install the add-on DMIS. Just check if your system’s release configuration is 1610 or higher or not. In that case, you are good to go.

Step – 2: Configure The Source Data System.

Now, you’ll need to create an RFC ABAP connection to the Source data system from the SLT system. In this case, you will need to fill up the following slots in a drop-down display menu known as RFC destination –

  • The RFC destination.
  • The connection type.
  • The Description 1 section.
  • The Target Host.

… and the IP address. 

The final option will probably be collected by the system automatically. But, if it doesn’t work for some reason, you will need to provide the same manually.

Step – 3: Begin Your SLT Configuration From The LTR Transaction.

Now, you will need to launch the LTR code you received from the system and start with your guided configuration. It, in turn, will help create the database connection to target the HANA database. Here is some additional information that you need to know in this regard –

  • Initial Load Mode: It’s possible to define an Initial Load Mode in case you want to opt for a specifically-different reading type. The “resource optimised” note will define the “default” mode of the system. It will utilise reading type 3 for all the tables. In any case, the “performance optimised” will use a reading type 4 or 5.
  • The Number Of Initial Load Jobs: This term defines a job that’s used in the initial load process within the SAP LT replication server.
  • The Number Of Calculation Jobs: This value will specify the number of access plan-related calculation jobs. All of these will be allocated by the provided config.
  • The Number Of Data Transfer Jobs: Unlike the former, this value will define the overall number of DTJs in your system. 

Step – 4: Start From The Source System.

At first, you will need to create a database view or a table. And once you are done, you have to start the replication procedure with the same DB. 

Please keep in mind that the process of initial load will begin in this aspect. And it may take quite a bit of time to load the data at the initial phase.

Anyway, once the replication process is active, you will need to perform the following steps to complete the procedure –

  • If the target system and the source are different, you have to create the rule assignment within the LTRS transaction code.
  • Also, don’t forget to verify the current schema mapping. If you feel like it, don’t forget to create a brand new mapping for your purpose.

Step – 5: The Post-Installation Viewpoint.

Once the procedure is complete, please check if the system has replicated everything as you needed it to. If everything looks alright, don’t forget to activate your SAP HANA. Here’s how you can do the same –

  • Go to the CAR system and start with transaction SE38.
  • Enter the term “/CAR/ACTIVATE_HTA” and click on Execute.
  • Select each and every applicable business scenario, source master data system, and scenario options as a whole.

The Final Say

So, what do you think? Could we convey the information you were looking for? Well, if you still are confused about something, please comment below. We’ll try to answer you as soon as we can. Thanks for reading!

Discover how our end-to-end solutions can help your business thrive. Read more about SLO and explore our success stories to see how we have delivered customised solutions that drive results.

Frequently asked questions

1. When is the DMIS add-on not required for SLT replication?

The DMIS (Data Migration Instruction Server) add-on is required for many older SAP systems. In SAP S/4HANA on‑premise releases, SLT‑related capabilities are included in the software stack, so you only need to check the installed components and release level before configuration.

2. What is the main difference between Option A and Option B for ABAP sources?

  • Option A deploys the SLT server on a separate system, helping to isolate the replication workload from the source system.
  • Option B installs SLT on the source system itself, simplifying the landscape but potentially increasing resource consumption on that system.

3. How does the connection method differ between ABAP and non-ABAP sources?

ABAP source systems typically use an RFC (Remote Function Call) connection, which allows for deeper integration and automatic creation of logging tables. ABAP systems typically connect through RFC, enabling the creation of triggers and logging tables by SLT. Non‑ABAP databases are connected through database connectors that require compatible drivers on the SLT host.

4. What is the difference between “Resource Optimised” and “Performance Optimised” modes?

These modes define how SLT reads data during initial load.

Resource‑optimised settings aim to minimise impact on the source system, whereas performance‑optimised options focus on accelerating data extraction but may require additional system resources.

5. What happens if the database connection to a non-ABAP source is lost?

In a non-ABAP scenario, database connectivity is the only “bridge.” In non‑ABAP scenarios, the database connection is essential for SLT to read changes. If connectivity is interrupted, replication may pause until the connection is restored. Unlike ABAP systems, non‑ABAP sources do not use SLT‑managed logging tables for buffering.

6. Why do I need to use the /CAR/ACTIVATE_HTA program?

In SAP Customer Activity Repository (CAR) scenarios, the /CAR/ACTIVATE_HTA programme activates the SAP HANA Transport Analytics objects after replication, enabling required structures for CAR reporting and analysis.

7. How can I manage specific table transformations during replication?

While the basic configuration happens in transaction LTR, more advanced requirements—such as filtering specific data or mapping schemas—are handled via transaction LTRS (Advanced Replication Settings). Advanced rules such as filters, field mappings, or transformation logic can be configured in transaction LTRS (Advanced Replication Settings) to define how SLT processes data before it is written to the SAP HANA target system.

Picture of Benjamin Ng

Benjamin Ng

Head of Marketing, cbs Asia Pacific

As Head of Marketing, Asia Pacific at cbs Corporate Business Solutions. Benjamin focuses on enterprise modernisation strategy across SAP landscape transformation, data-driven innovation, and AI-enabled business models. He works closely with regional leaders and ecosystem partners to shape outcome-led transformation programmes across APAC.

Linkedin
Related articles
oneascent-m&a-image-4
Insight
A Safer Way to Manage ERP Change During M&A
Read More
14. March 2026
oneascent-m&a-image-3
Insight
Why ERP Systems Make Divestitures and Carve-Outs So Difficult
Read More
14. March 2026
When a merger, acquisition, or divestiture is announced, the spotlight is usually on the strategic story. Market expansion. Portfolio optimisation. Synergies. Shareholder value. Behind closed doors, deal teams are working intensely on valuation models, legal structures, and regulatory approvals. Leadership teams focus on how the new organisation will operate once the transaction is complete. Technology rarely sits at the centre of these discussions. And yet, once the deal is signed, it often becomes the hardest problem to solve. Where the real complexity begins In large enterprises, ERP systems sit at the centre of how the organisation actually runs. Finance reporting, procurement, supply chain operations, manufacturing processes, and compliance controls are all deeply connected through the same digital core. Over time, these systems evolve into highly integrated environments. Multiple legal entities may share the same ERP instance. Business units that look independent on an organisational chart may rely on shared data structures, reporting frameworks, and operational processes inside the same system landscape. This works well when the organisation remains intact. It becomes far more complicated when the structure of the business changes. When a company sells a division, spins off a business unit, or acquires another organisation, those shared systems suddenly need to be separated, replicated, or reorganised. Data structures that support several entities may need to be redesigned. Reporting environments must remain stable even as the underlying systems change. And this often needs to happen under strict deal timelines. Why ERP challenges appear late One reason ERP complexity catches organisations by surprise is timing. In many transactions, technology teams are brought into the conversation only after the deal structure is already defined. By that point, legal agreements are signed, Day-One deadlines are set, and the operational expectations of the new organisation are already clear. What becomes visible at that stage is the gap between the business structure of the deal and the technical reality of the systems that support it. Separating a business entity on paper may take weeks. Separating it inside an ERP system can take months if the dependencies are not fully understood. When technology risk becomes business risk This is where technology stops being a purely IT concern. If ERP systems cannot be separated cleanly, finance reporting may be affected. Regulatory obligations may become harder to fulfil. Supply chains and operational processes may experience disruption. Integration timelines can extend far beyond what deal teams originally expected. In other words, ERP complexity can quickly become a business continuity risk. This does not mean that mergers, acquisitions, and divestitures are inherently problematic from a systems perspective. Organisations execute these changes successfully every year. But the most successful programmes share a common mindset. They recognise early that enterprise systems are not just operational tools. They are structural components of the business itself. Treating ERP as part of the deal strategy When ERP landscapes and enterprise data structures are considered earlier in the transaction process, organisations gain much greater control over execution. Dependencies between business entities become visible sooner. Separation or integration scenarios can be evaluated earlier. Technology teams can design approaches that protect operational continuity while still supporting the strategic intent of the deal. This shift in thinking is becoming increasingly important. Modern ERP environments support far more than financial accounting. They underpin operational processes, regulatory reporting, supply chain coordination, and increasingly the data foundations that support analytics and AI. Changing the structure of the business inevitably means changing the structure of the systems that run it. For organisations navigating mergers, acquisitions, or divestitures, the real question is no longer just how to close the deal. It is how to execute the change without destabilising the systems that keep the business running. Over the coming weeks, the ONE.Ascent campaign will explore how enterprises approach ERP change during structural events such as mergers, acquisitions, and divestitures, and what separates high-risk programmes from those executed with confidence. Continue the Conversation If your organisation is navigating a merger, acquisition, carve-out, or divestiture, join our upcoming ONE.Ascent executive webinar where we explore the practical realities of managing ERP change during structural transformation. Register for the session or explore the ONE.Ascent campaign hub to see how enterprises across the Asia Pacific are approaching modernisation with greater clarity and control.
Insight
The Hidden ERP Risk in M&A: Why Technology Becomes the Hardest Part After the Deal
Read More
14. March 2026