Process Flow for the Migration 
Purpose
Migration projects can differ greatly from one another due to the many possible initial situations and target scenarios and may also have greatly varying time requirements. For these reasons, the migration process described here can only take a standardized form, containing the central tasks.
Process Flow
● Start of the Migration Project
Like any other project, the migration project needs to have a concrete start. During the start process, aspects such as project organization, schedules, and procedures are determined. The start can occur before the upgrade to mySAP ERP 2005.
● Analysis of Initial Scenarios
The initial situation can be analyzed before the upgrade to mySAP ERP 2005. Some of the aspects discussed in the section Steps of a Migration Project, such as interfaces to external systems or the consideration of the effects on the migration on other SAP modules, require a long lead time in case you need to make adjustments in the external systems or other SAP modules.
● Upgrade to mySAP ERP2005
The upgrade to mySAP ERP 2005 is the prerequisite for using the actual migration support provided by the system. The upgrade itself – with all its subtopics and test requirements – is a project in its own right. As part of the migration project, it should be made clear here that the overall time requirement for the migration can include and influence the upgrade.
The points that can be dealt with before the upgrade can, of course, also be performed after the upgrade has been performed successfully if you want to separate the two projects from each other.
● Customizing of New General Ledger Accounting
First, you should set up the new environment completely in New General Ledger Accounting. This also forms the basis for subsequent validations.
● Creation of a Migration Plan
This is the system view of the actual start of the migration, which provides the framework for the following activities.
● Customizing Settings for Migration
In contrast to the standard settings for New General Ledger Accounting, you can make special migration Customizing settings here for document splitting. Subsequently, this also influences the test migration and the subsequent actual migration.
● Test Migration
The test migration is performed in iterative steps. You determine and select the data to be migrated, and then you start a migration trial run using the Customizing settings for New General Ledger Accounting and using a log. Analyzing the log tells you which data could not be migrated and why. You then need to adjust the Customizing settings, create exception rules, or take other measures. Afterwards, you perform another test migration. You repeat this process is repeated as often as necessary until:
■ No existing data causes problems or cannot be migrated
■ As a result of using validation in the project, you are sufficiently certain that any new documents posted will not cause any problems.
As a final step, you transport all the test settings to the production system.
● Validation
You use validation to ensure in the production system that the current posting activities are also adapted step by step to your new posting logic. Performing validation is only useful if a new posting logic is introduced. However, at this point, it should already be clear from the migration project whether this is the case.
● Actual Migration
In contrast to the test migration, you do not perform the actual migration iteratively. Instead, you perform it just once, and you do so in the production system. Beforehand, you copy from the test system to the production system all relevant specifications for the migration that you have obtained by performing the test migrations, and complete all other preparatory tasks.
● End of the Migration Project
Once you have performed the actual migration successfully, the migration to New General Ledger Accounting is complete. You may be required to perform migration activities in other application components, be it before, after, or alongside the migration.