Show TOC

Migrating Existing Data Flows ManuallyLocate this document in the navigation structure


To migrate an existing data flow, we recommend using the system-backed automatic migration in transaction RSMIGRATE. More information:Migrating Data Flows.

The following sections outline what you need to consider and how you proceed when migrating a data flow manually.


In the procedure outlined here, we make the following simple assumptions:

  • You intend to migrate the data flow without making any changes to the transformation logic and the InfoSource (which is optional in the new data flow) is to be retained.
  • In the data flow, one DataSource is connected to multiple InfoProviders. All objects required in the data flow exist as active versions.
Preliminary Remarks
  • Always migrate an entire data flow, thus including all objects that it contains, from the InfoProvider down to the DataSource.
  • Do not migrate the data flow in a production system. The recommended procedure differs depending on whether your landscape is a two-system (development system and production system) or three-system (development system, test system, and production system) landscape. You generate the new objects in the development system, run tests in the development or test system (depending on your system landscape), and then transport the new objects, as well as the deletions of the 3.x objects no longer required, in the production system. Note that the transports are made in the same sequence that they were created in.
  • When you model a data flow using the new object types, you use the emulation for the DataSource. This affects in particular the evaluation of settings in the InfoPackage, because in the new data flow, it is only used to load data into the PSA. The emulation makes it difficult to use InfoPackages because only a subset of the settings made here is evaluated. In the new data flow, the settings not evaluated by the InfoPackage must be made in the data transfer process. You are therefore advised to consider these dependencies when emulating the DataSource and to emulate your DataSource in a development or test system only.

    More information:Emulation, Migration and Restoring DataSources andUsing Emulated 3.x DataSources.


Carry out steps 1-6 and 8-9 in the development system:

  1. For each InfoProvider that is supplied with data from the DataSource, generate a transformation from each of the update rules.

    Copy the 3.x InfoSource to a new InfoSource.

  2. Generate a transformation from each of the corresponding transfer rules.

    Remember to use the existing InfoSource that was created when the update rules were migrated.

  3. Make any necessary adjustments to the transformation.

    You need to postprocess a transformation if you use formulas or inverse routines in your transfer rules for example. You can also adjust the routines to improve performance.

    For more information about steps 1-3, seeMigrating Update Rules, 3.x InfoSources and Transfer Rules.

  4. Create the data transfer processes for further updating the data from the PSA.

    In the new data flow, the data transfer process uses the settings from the InfoPackage that are relevant for updating the data from the PSA. More information:InfoPackage -> Data Transfer Process.

    1. In InfoPackage maintenance, navigate to the Data Targets tab page.
    2. Create a data transfer process for each of the InfoProviders that is supplied with data from the InfoPackage.
    3. To do this, choose Error! Objects cannot be created from editing field codes. under Create/Maintain DTP with the quick info text Create New Data Transfer Process for This Data Target.
    4. Check all DTP settings that you want the DTP to use in the new data flow for the InfoPackage.
      • On the Update tab page, check the settings for error handling.
      • On the Extraction tab page, check the extraction mode.

    For more information about data transfer processes, seeCreating Data Transfer Processes.

  5. In the InfoPackage, check on the Data Targets tab page that any InfoProviders that are supplied with data by means of update rules are not selected. This allows you to ensure that the InfoProviders are subsequently only supplied with data by the new data flow.
  6. Check the process chains that are used in the data flow and make any necessary adjustments.
    1. Open the process chain from InfoPackage maintenance by choosing Process Chain Maintenance.
    2. Insert the DTPs into the process chain directly after the InfoPackage.
    3. Make any adjustments required in the subsequent process (previously InfoPackages, but now DTPs).

      If the process variants previously referred to the object type InfoPackage, you now need to specify the corresponding DTP, when activating the data in the DataStore object for example.

  7. Test the data flow.
    • If you have a two-system landscape, run the test in the development system.
    • If you have a three-system landscape, first transport the affected objects to the test system and test your new data flow there.
  8. Migrate the DataSource.

    The migration process generates a new DataSource. The 3.x DataSource and the transfer structure and mapping are deleted. The PSA and InfoPackage are used in the new migrated DataSource.


    When the DataSource is migrated, the InfoPackage is not migrated in the sense of a new object being created. After migration however, only the specifications about how data is loaded into the PSA are used in the InfoPackage. Existing delta processes continue to run. The delta process does not need to be reinitialized.


    You can convert a migrated DataSource to a 3.x DataSource if you export (restore) the 3.x objects during migration.

    More information:Emulation, Migration and Restoring DataSources andMigrating 3.x DataSources Manually (SAP Source System, File, DB Connect).

    XML and UD-Connect 3.x DataSources cannot be migrated. Conversion to the new DataSource concepts is made by copying the 3.x DataSource to the new object type. More information:Emulation, Migration and Restoring DataSources andMigrating 3.x DataSources (UD Connect, Web Services).

  9. To ensure greater transparency, you should delete the 3.x InfoSource and update rules.
  10. If you have a three-system landscape, transport the migrated DataSource and the deletion of the 3.x InfoSources and update rules into the test system.
  11. Examine the data flow for completeness and check that any objects that are no longer required are deleted.
    • In a two-system landscape, do this in the development system.
    • In a three-system landscape, do this in the test system.
  12. Finally, transport the objects and deletions from the development or test system into your production system.

You have migrated a 3.x data flow and can now benefit from the features of the new concepts and technology.

Migrating Data Flows That Use the Data Mart Interface

You cannot migrate export DataSources that are used when the data mart interface is used to update data from one InfoProvider to another InfoProvider. However, a data flow that uses export DataSources can be migrated to the new object types, because the export DataSource and its transfer and update rules can be modeled in the new data flow using DTPs and transformations. The data flow can be migrated as outlined above. However, the actual migration of the DataSource and the corresponding steps involved are omitted.