SystemCopyandMigration

1. What takes place during a homogeneous system copy?

The main purpose of a homogeneous system copy is to build a test, demo or training system or to move a system to
a new hardware. The difference to a heterogeneous system copy is that both the database and operating system
remain the same. Because of this, there is the possibility on some platforms to perform the copy using databasedependent methods (such as backup/restore). Note that no matter if you change the version or bit version of either
the operating system or the database, the system copy is still considered to be a homogeous system copy (for
example, the system copy from Microsoft Windows 2000 32-bit to Microsoft Windows 2003 x64).

2. What takes place during a heterogeneous system copy

(migration)?
The main purpose of a heterogeneous system copy is to create a copy of an already existing SAP system on the
platform where either operating system, or database, or both differ from the operating system/database of the source
system. The whole migration process consits of five main steps (described in detail in the system copy
documentation):
1.

Preparation steps on the source system

2.

Export of the source system data into database-independent format

3.

Transfer of the exported files to the target host

4.

New system installation together with data import

5.

Post-processing steps within the target system

3. Which tools are used during a migration on source and target

systems?
The main programs used for the migration - depending on the kernel release - are R3SETUP, SAPinst or software
provisioning manager. During execution, they call other programs for particular purposes (such as R3LOAD,
R3LDCTL, R3SZCHK) that use different command files. For a technical overview, see this document.

4. What is the purpose of the files that are used during a migration?

DDL<db_type>.TPL is used for creation of table/index definition in database-specific syntax

and contains negative list of tables, views and indexes, assignment of TABARTs to storeage unit and
next extent size of table/index. TABART stands for a data class. For more information, see SAP Note
46272 (SMP login required).
SAP<TABART<.STR contain table/index definitions from the ABAP Dictionary.
SAP<TABART.CMD contain definitions of path and names for
corresponding STR, TOC, EXT files,DDL<db_type>.TPL, export directory, block and file sizes.
SAP<TABART>.<nnn> (<nnn> = 001, 002, ...), so called dump files, contain the data of all tables

of a tabart in a non-platform-specific file format. These are binary files and they should never been
changed/edited!
SAP<TABART>.EXT contain initial sizes for tables and indexes. Not applicable to some

databases (such as for Microsoft SQL Server).

SAP<TABART>.TOC contain position of table data within the corresponded dump file, name of
the dump file, time stamp of unload, and table rows number. TOC files must never be changed without
approval of SAP support.
SAP<TABART>.log contain log file information in case of errors and for restarting.
SAP<TABART>.TSK are files used by R3load - for more information, see SAP Note 455195 (SMP
login required).

5. What interdependencies to kernel versions have to be

considered?
For the ABAP kernel tools used during a migration, some rules should be followed:
1.

Tools used at the export on the source system must have the same version as on the target
system.

2.

3.

Tools used must all have the same kernel version (do not mix up kernel tools of different
releases, as otherwise, different versions of the called programs - such as R3load - might be used for
export and import).
Tools must have the same kernel release as the system that is migrated.
These rules should be applied, unless specified otherwise in an installation/migration SAP Note or documentation.
Keep this in mind when downloading a patched version of any mentioned tool from SAP Service Marketplace!
The Java system copy tools do not depend on the kernel version and you can always use the latest version of
these tools.
For more information about dependencies to kernel versions for ABAP and Java systems, see SAP Note
784118(SMP login required).

6. What requirements should be met before a migration starts?

See SAP Note 82478 (SMP login required).

7. Is a migration of a specific product/OS+DB combination

supported?
First, check whether both the source and the target product/OS+DB combination is supported - for this, refer to
thePlatform Availability Matrix available in SAP Service Marketplace at: http://service.sap.com/pam (SMP
login required).
In addition, check both the system copy documentation and the relevant SAP Notes for any possible restrictions.

8. Where can I find information on how to optimize the overall

runtime of a system copy?
See the corresponding documents on the System Copy and Migration document.

9. Is it possible to perform a final migration of a productive system

without a "test" run?
No, you should always perform a test migration on a comparable hardware with a system that is using a copy of the
production database. This is necessary both to get an idea about the overall runtime of the production migration and
to recognize possible major issues of the procedure before the final migration