Migration strategies are used in information technology to migrate systems in order to replace them.

Kafka is a scalable, reliable and highly available platform that can achieve high throughput. Therefore, applications that use Kafka are decoupled from each other and communicate only through these Kafka topics. Because messages can be persisted in Kafka, messages that are written faster than they are read can be retrieved and processed later.






To be successful, a migration must meet at least the following requirements:

  • guarantee uninterrupted, secure, reliable operation: A company cannot cope with failures of central systems such as operational information systems over a longer period of time; even the shortest failures lead to (financial) losses.
  • make as many changes as it seems necessary to cover current and future expected requirements: this ensures that the new system does not have to be adapted shortly after completion of the migration, and that another migration may be required.
  • Make as few changes as possible to reduce the scope and risk of the migration: the more complex a migration is, the higher the risk of errors; the complexity of a migration increases with the number of changes made.
  • change old code as little as possible to minimize risks: as long as the code works and no new functionality is needed, it should be kept as it is, or only minimal changes should be made, as changes will inevitably introduce bugs in the implementation. However, this principle is usually not applied, as the whole system is redeveloped without adopting any code.
  • Change old code to support migration: if changes can be made to the code with reasonable effort to simplify migration, this should be done.


Analysis of the legacy system: For a successful migration, it is essential to first understand how the legacy system works. Hopefully existing documentation will help here, otherwise Reverse Engineering.

Disassembling the legacy system: The legacy system must be changed to the extent that defined interfaces exist between the individual modules and the database backends.

Develop the interfaces of the target system.

Developing the target applications: Consideration of whether the functionality of the legacy system application should be replicated, or should only be as close as possible to that of the legacy application.

Developing the database backend: Here the results of the previous steps are included, recommended is the development with a relational database based on SQL.

Installing the target environment: Setting up a test environment and testing this environment.

Development and installation of Gateways: The gateways are responsible for extracting data from the legacy system and transferring it to the target system.

Migration of the database of the old system: Installation of the new database system, then migration of the data between the old and the target system.

Migration of the legacy applications: Gradually replacing the individual modules of the legacy applications and integrating them into the overall system.


The S/4HANA Finance Ledger concept enables the use of parallel multi-GAAP accounting to meet the accounting principles relevant to your business.

Parallel Ledger

The parallel ledger concept makes it possible to depict different accounting standards (e.g. HBG, IFRS, US-GAAP etc.) in parallel. Each of the parallel ledgers represents a specific accounting view. Valuation and closing operations can thus be carried out individually according to accounting standards. With S/4HANA, you comply with your underlying accounting standards simultaneously, without the need for redundant data storage.

Talk to

Daniel Ring!