Skip to Content
Software Logistics

FAQ - System Copy and Migration

Tags:

This document provides frequently asked questions for the installation of SAP systems. In addition, also see SAP Note 547314.

01. 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 database-dependent 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).

02. 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

03. What post-copy activities are required?

To bring the target system into operation and to adapt it to its new identity, several post-copy activities are required, such as:

  • Cleaning up settings that got copied from the source system, but are no longer valid for the target system (such as cleaning up of ABAP basis tables, batch jobs, DBA cockpit configuration,  RFC in/outbound queue, spool requests, and TRUST manager configuration)
  • Adapting the configuration of the target system (that is, adaptation of basis and application-specific configuration settings, such as the configuration of standard jobs, licenses, logon groups, system profiles, operation  modes, secure store, spool and TMS, and the scheduling in the DBA planning calendar)

The post-copy activities are described in the system copy guide. In addition, see the blog How to Deal with Landscape Data Created during System Copy for information how to adapt corresponding data in the system landscape directory (SLD).

Instead of performing required tasks for post-copy manually, you can optionally use automation  to perform configuration tasks in an automated way. This is offered by SAP Landscapce Virtualization Management, offering an automated end-to-end system copy and refresh procedure, where you get guided through the configuration processes and benefit from automated post-copy configuration tasks reflecting SAP expert knowledge. This results in less effort and cost, faster configuration procedures with less expertise required, and a higher reliability and a ‘standardization’ of tasks.

04. Which tools are used during a migration on source and target systems?

The main program used for the migration is Software Provisioning Manager. During execution, it calls other programs for particular purposes (such as R3LOAD, R3LDCTL, R3SZCHK) that use different command files. For a technical overview, see this document.

Depending on the kernel release, former tools might be involved, such as R3SETUP and SAPinst.


05. 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).

06. 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. 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).
  3. 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 Help Portal!

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).

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

See SAP Note 82478 (SMP login required).

08. 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 the Platform 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.

09. 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.

Especially for the migration of ABAP systems to SAP HANA, see the Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA.

10. 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.

11. What aspects do I have to consider for a migration to SAP HANA?

For more information about a migration to SAP HANA, see the document Classical Migration to SAP HANA, which provides further details, such as an overview and further details of the procedure, best practices, demo video, and more information about options to minimize the downtime.

12. Are there alternative approaches to a classical system copy?

Yes, depending on your use case, several alternatives exist:

  • The system rename procedure can be a faster alternative to the classical system copy for certain scenarios, as it allows to quickly adapt key characteristics of an SAP system (such as hostname, system ID, instance number) or to make cloned systems operational.
  • The product SAP NetWeaver Landscape Virtualization Management helps customers simplify and optimize provisioning, deployment, and management of their SAP systems through the use of virtualization and Infrastructure as a Service (IaaS) cloud technology. One of its key features is a framework for SAP system cloning, copy and refresh, including fully automated post-copy tasks, eliminating manual effort. Customers can use it to reduce the total cost of operations of their SAP system landscape and enhance their flexibility and business agility.
  • Especially for the migration of ABAP systems to SAP HANA, further options exist as outlined on the Migration of SAP Systems to SAP HANA page.