Several advantages at once
SAP system deployment scenarios
Unsorted unloading: - By default, R3load sorts table data by primary key before export. This requires time and resources in the source system. Under certain conditions, this sorting can be omitted.
If the data stocks become obsolete, they can be updated by another system copy. From a technical point of view, such a refresh corresponds to the initial setup, including the associated costs as well as the load on the productive systems and manual rework. In addition, a refresh also interrupts all processes on the target system. If it is a development system, all newer development objects must be saved and transported back in after the copy. The version history is lost in the process.
A note box in which data of all kinds can be quickly filed and retrieved. This is what Scribble Papers promises. At first, the program looks very spartan. But once a small structure is in place, you realise the great flexibility of this little helper.
Copying needs to be done skillfully
Different DDLORA* files can be assigned to the R3load packages. The assignment is done by a text file, which is given to the MigrationMonitor as parameter 'ddlMap = mapDDL.txt' and evaluated by it.
In the case of BSC, sophisticated mechanisms make it possible to exclude configuration errors, since relevant parameter settings are made automatically and according to predefined rules. For example, it is automatically recognized whether the system is an Abap, Java or double-stack system.
SAP system copy can be done easier and faster with "Shortcut for SAP Systems".
One takes thus in the context of the copy a platform change.
On www.sap-corner.de you will also find useful information about SAP basis.
Tables that should be saved beforehand in the old target system.