Show TOC

 Migrating Application Projects from SAP NetWeaver 7.0 to a Higher SAP NetWeaver VersionLocate this document in the navigation structure

The following documentation describes the processes and tools you need to use if you want to migrate your SAP NetWeaver 7.0 development projects to the development tools and infrastructure provided by a higher version of SAP NetWeaver. Typical migration scenarios are:

  • You have started your development projects on SAP NetWeaver 7.0 but you now want to make use of the technology, innovation and competitive advantages that a new version of SAP NetWeaver brings to the market;
  • You need to ship (and maintain) your applications to new customers who are running a higher SAP NetWeaver version.

If you are only interested in migrating the runtime of an SAP NetWeaver 7.0 system (including all applications running on it), you should follow the standard upgrade procedure. This provides tools that automatically migrate applications at runtime and do not require the manual migration of the application source code.

Exception to this rule are:

  • Composite Application Framework (CAF) applications - these applications always require design-time migration prior to migration of business data at runtime.
  • Web Dynpro applications - these have to be migrated at design time (usually repair project and rebuild) and be newly deployed. You only have to do this for your own applications, SAP's applications are migrated by SAP.
  • Portal applications - these applications have to be migrated explicitly, since their deployment format has changed.

    The information in the current section does not apply to the portal applications. Instead, see Migrating Portal Applications .

  • JDO applications

    Applications using Java Data Objects (JDO) need special attention. Though the applications themselves can be compiled and built with JDK 6, the actual JDO classes need to be compiled with JDK 1.5 or with JDK 6 using the "-target 1.5" option. JDO classes can be easily detected by their accompanying .jdo and .map files.

    The requirement to use JDK 1.5-compliant build target results from the fact that the class files of JDO classes need to be post-processed by a tool known as the JDO enhancer. The class file format was significantly changed with JDK 6. However, the JDO enhancer does only support the JDK 1.5 class file format. Therefore, JDO classes must be compiled in such a way that the JDK 1.5 format is used for the class files. This can be achieved by using JDK 1.5 directly or JDK 6 with the option "-target 1.5" in the build.

For more information about standard upgrade procedures, see the corresponding upgrade guide for your target system at .

Migration Process

  1. Set up the migration environment.

    Before the application projects can be migrated, the development track in which your development components reside must be migrated first. This is necessary because in certain cases, the software components required by an application after migration may differ from those it required as an SAP NetWeaver 7.0 application.


    Since SAP NetWeaver 7.0 tracks use an old JDK version, it will be necessary to install the correct JDK required by the new track. Note that there are incompatible changes between different JDK versions. Such incompatibilities may lead to errors in newly-migrated applications. For more information, see Migration from JDK 1.4.2 to JDK 6 .


    We recommend that you complete the migration of your custom code in all existing SAP NetWeaver 7.0 tracks before deleting them.

    For more information, see Migrating Tracks Content from SAP NetWeaver 7.0 to Higher Version .

  2. Run the migration wizard to automatically adapt the old project's nature (for example, project's metadata, artifacts, and structure) to the new one.

    For more information, see Running the Application Projects Migration Wizard .

    Note that the migration wizard does not provide support for migrating APIs or adapting an application's architecture to a new programming model (for example, the new component architecture in Web Dynpro Java).

    However, for Web Dynpro Java projects, there is a tool you can use to repair the internal API usage of an application after migration. You can start it from the context menu of the Web Dynpro project in the Web Dynpro Explorer. Choose Repare  → Internal Web Dynpro API Usage.

  3. An application project might have been migrated only partially. In such a case, you have to perform manual migration steps to ensure the successful application migration.

    You have to copy the old sources and new libraries to the new track. Note that this may result in a non-compliable state. Then you have to import the development configuration of the new track to the SAP NetWeaver Developer Studio, and complete the migration process in the Developer Studio.

    Review the following sections for information about completing a partial migration: