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:
More information:Emulation, Migration and Restoring DataSources andUsing Emulated 3.x DataSources.
Carry out steps 1-6 and 8-9 in the development system:
Copy the 3.x InfoSource to a new InfoSource.
Remember to use the existing InfoSource that was created when the update rules were migrated.
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.
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.
For more information about data transfer processes, seeCreating Data Transfer Processes.
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.
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).
You have migrated a 3.x data flow and can now benefit from the features of the new concepts and technology.
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.