As I talk with SAP users at various events, two main SAP ERP Financial topics continue to draw a high level of interest and many questions. They are:

• The SAP General Ledger, now available in SAP ERP 6.0, and the migration process
• Enhanced financial closing and the SAP Financial Closing Cockpit

I first covered the migration topic in my article, “Migrating to the New General Ledger: A Three-Phase Approach.” I then reviewed SAP’s vision for the enhancement of the financial close and several configuration tips for the SAP Financial Closing Cockpit in my article, “Set Up SAP Closing Cockpit for Speedier and Better-Controlled Financial Closings in 5 Steps.” 

In this article, I’ll update the information contained in that earlier migration article. Since then, SAP has updated several product names and concepts. Here is a short summary:

• mySAP ERP 2005 was renamed SAP ERP 6.0
• The migration phases then numbered 1 to 3 are now referred to as phases zero (0), 1, and 2
• The earlier article focuses on the IMG steps to complete the entire migration process. Now a migration back-office support team provides required migration support services, including GL migration cockpit.
• The new G/L is now referred to as the SAP General Ledger (SAP GL)

The major difference in the SAP GL migration during the last two years has been the change in the overall migration process. Currently, companies that plan to migrate to the SAP GL must engage with the SAP migration support team in Germany and use the new migration cockpit to guide and document the entire project. This engagement between migrating companies and the SAP back-office migration support team is now a mandatory requirement.

Migration Support Team

The migration support team provides the following services for all migration projects:

1. A scenario-based migration cockpit custom configured for each migration company’s objectives
2. One feedback session and two remote service sessions at specific times during the project
3. Back-office technical support during the migration weekend

1. Scenario-based migration cockpit. The migration cockpit is delivered to each company and is configured to include all the migration steps that are required to complete each company’s specific project. An example is a company that is planning to move to the SAP GL without using document splitting. The delivered version of the migration cockpit would not include any of the process steps required to test the splitting configuration. If, on the other hand, the splitting option is included within the initial project design, the delivered migration cockpit would include the steps required to test and validate the document splitting rules completed during the SAP GL configuration.

Figure 1 displays the current version of the migration cockpit with the option of scenario 3, Document Splitting selected. Note the migration steps required for the checking of document splitting have been included. If scenario 2 had been selected, no document splitting steps would have been included in the cockpit because scenario 2 does not include document spitting.

Figure 1

SAP GL migration cockpit

2. Feedback and remote service sessions. The migration back-office team engages directly with migration companies at three points:

• The first is a feedback and discussion session between the migration back-office team and the migration project teams. The objective is to determine the correct migration scenario that the company needs to meet its project objectives. The discussion during this feedback session is guided by the company’s migration application document. This application document/questionnaire is part of the overall engagement process that I will outline later in this article. After completing the feedback sessions and discussions, the migration company is expected to sign a formal statement of work (SOW). After the back-office team receives the signed SOW, it delivers the appropriate migration cockpit to the company.
• The contact with the back-office team in Germany is service session 1. The objectives of the first service session are the validation of the correct scenario selection, pre-testing, and configuration of the migration plan that has been completed to date. This session is normally held prior to any actual data migration and typically before the close of the current fiscal year.

• Service session 2 occurs a few weeks prior to the actual migration weekend. You review the migration test results and if everything looks good at this point, the actual migration of real production data can proceed.

At the conclusion of each service session, the migration back-office team prepares a comprehensive report detailing the specific project status and any problems that could arise during the migration weekend.

3. Back-office support during migration weekend. Actual data migration on the productive systems normally occurs during a single weekend. During this weekend, the migration back-office team provides 24-hour contact for migration support. This on-call support has proven to be of high value in several of the completed migration projects. In each case, the on-call technical expert has helped resolve unexpected issues, and the migration projects were all completed within the planned system down-time period.

You should know a few other things regarding the migration back-office team support:

• It is required. No company has access to the migration cockpit without the engagement of the back- office team.
• The IMG method is no longer available for migration projects. The migration cockpit is the only tool allowed for migration.
• Before any company can have access to the migration cockpit, there must be an SOW in place between the SAP back-office support team and the company.
• The migration back-office team is not responsible for configuration errors with the SAP GL configuration. For example, if an error occurs within the document splitting configuration during the migration, this issue must be solved by local consulting resources or the normal SAP support channels. If an error occurs in the actual processing of documents as they are passed into the various migration work lists, the migration support team will address this issue.
• For further information about services provided by the migration support team, go to https://service.sap.com/GLMIG.

Migration Project Phases

For the final part of this article, I’ve included two additional screenprints to help illustrate the typical migration project.

Figure 2 is a high-level overview of the migration project and the typical sequencing of project steps. As shown in Figure 2, you must complete the upgrade to an SAP ERP release prior to any consideration of the SAP GL. SAP currently recommends that upgrading companies go directly to the latest SAP ERP release, SAP ERP 6.0. As part of the upgrade to SAP ERP 6.0, you should install SAP Enhancement Package 3 (EhP 3). EhP 3 adds significant new features and functions to the SAP GL not included in the earlier version. For more details on the contents of EhP 3 and other EhPs, go to https://websmp206.sap-ag.de/gl and click on the Enhancement Package link.

Figure 2

Project time line for an SAP ERP upgrade and SAP GL migration

As another general point, it is not a good idea to plan the SAP GL migration project to take place during the same time as the upgrade project. It’s better to wait for the upgrade to be completed and stabilized and then begin the SAP GL migration project. As you can see from Figure 2, the SAP ERP upgrade project is highlighted as a separate project, followed by the overall SAP GL implementation/migration project.

Note that the implementation/migration project is broken down into three separate phases. The first step of the overall implementation/migration project is the blue- printing of the configuration of the SAP GL. Next is the actual customizing, testing, and implementation of the SAP GL.

After implementation, you can begin the final project step by planning and testing before you actually migrate the data. At this point, you should set up a separate sandbox system to test the SAP GL configuration and later the migration plans.

Overall, when considering the migration to the SAP GL you should also allow for time and costs to set up and test the SAP GL. This project phase can take as long as six months and must be completed before beginning any phase of the migration project.

Next consider Figure 3, which shows the SAP GL migration suggested time line. The contents and suggested time line referenced in Figure 3 are based on the optimal time line suggested by the various SAP GL implementation/migration projects completed to date.

Figure 3

Suggested time line

The key points of Figure 3 are the date of migration, migration weekend, the date of final activation, and phases zero (0), 1, and 2. The phases are as follows:

• Phase Zero (0): “Old” fiscal year — ends with the last day of the fiscal year
• Phase 1: “New” fiscal year — year in which migration and activation takes place
• Phase 2: SAP GL is live and the system blocks posting to the classic General Ledger (classic GL)

Date of Migration

It is a requirement that the date of migration is a fiscal year-end. You should set this date as the upcoming fiscal year-end rather than one in the past. If you use the upcoming year-end, the actual migration process is much less complex. The selection of this date tells the migration program how to identify the correct open items and the year-ending balances that you migrate into the SAP GL data tables during the migration weekend.

Note that this is not the actual calendar date that the data is copied between systems. This date of migration (fiscal year-end) allows the migration plan to find the correct balances, open items, and range of documents to be included in the various work lists constructed during migration. In other words, it serves as the data selection setting.

Migration Weekend

This weekend is the actual calendar date when you copy the data and documents from the classic GL source tables into the SAP GL new data tables. For example, the classic GL summary table is GLT0, while the SAP GL summary table is FAGAFLEXGLT.

For the data migration to be effective, it is important to identify the correct source of all data that you need to migrate. It is often the case that the classic GL totals table GLT0 does not contain all the data that is needed to fully populate the new summary table FAGAFLEXT. As an example, the system normally stores profit center data in Special Ledger tables. Again, experienced migration on-site support is critical for success.

Date of Final Activation

This date often occurs much later in the fiscal year, well after migration weekend date. You use the period between the migration weekend and the final activation date for the testing and final validation of the migrated data. It also serves as a final check of the final configuration of the SAP GL. Because this phase is critical to the success of the entire project, it can easily be the longest phase of the project.

This date is crucial because once the final activation of the SAP GL takes place, you can’t return to the classic GL. Therefore, you must ensure that the configuration of the SAP GL is correct and that all migrated data is consistent with the prior postings within the classic GL.

Phases Zero (0), 1, and 2

Refer again to Figure 3 for help with the following explanations. Note in which phase the classic GL and the SAP GL run solo and then in parallel. The classic GL is solo in phase zero (0). The classic GL and SAP GL run in parallel during phase 1. The SAP GL is solo after the classic GL permanently switches off in phase 2.

Also, note that the project time line from phase zero (0) to phase 2 as represented in Figure 3 can be an entire calendar year with phase zero (0) starting during the first quarter of the migration year and ending with phase 2 in the fourth quarter of the migration year. Again, based on previous migration projects this is an ideal time line, but your local project and individual circumstances may influence the actual time line available. Regardless of the actual time line for your project, you still must complete all the activities listed.

The migration model in Figure 3 is based on the experience of SAP’s key migration consulting specialists within the American market. As of August 2008, we have successfully completed 11 migration projects using this model. Some companies have attempted to complete their projects using a different migration model and time line. To date, each of these projects has encountered some difficulty in the migration process and deviations from the expected results.

Activity Details by Phase

Next I’ll provide more detailed information about phases zero (0), 1, and 2.

Phase zero (0). Phase zero (0) can be the longest of all three phases. Its length depends on the project start date and how long it takes to complete the following phase zero (0) tasks: project blueprinting, project planning, SAP GL configuration, development landscape setup, orientation workshops, and final configuration and testing of the migration cockpit.

Generally, this phase starts with an on-site workshop reviewing the SAP GL’s setup and capabilities. During this workshop, you discuss and develop an SAP GL configuration blueprint and project plan. The overall objective of this on-site workshop is to reach a general agreement between SAP and the host company that migration is possible within the available time frame and that the desired outcomes are reasonable and achievable.

After the on-site workshop, the next step is to establish a sandbox landscape in which you configure and test the SAP GL. You should engage a well-qualified GL consultant during the configuration of the SAP GL. During previous migration projects, many issues surfaced regarding data quality, data sources, and document splitting. The availability of an on-site GL expert will aid in the configuration and later in the migration process.

After the initial workshop, you move on to configuring the SAP GL. After you finalize the project blueprint, you need to reach out to the SAP migration back-office support team and formally apply for the migration support service. The back-office support team then sends back a formal migration questionnaire. The migration company completes and returns the questionnaire and then schedules a feedback session with the back-office team. The objective of this session is to determine the migration scenario that is appropriate for the company’s GL design.

After reaching an agreement, the company completes a formal SOW and returns it to the back-office team, which in turn releases the keys to the pre-configured migration cockpit. You activate the migration cockpit by using transaction code CNV_MBT_NGLM. This code is not active within your system until the back-office team activates it. You gain access to the migration cockpit by entering the transaction code in the SAP menu screen.

Then you can begin testing. The data tested during this period should include open items and non-open item managed account balances. Plan to use the prior year’s data to get a better picture of the data quality. You can transport the prior year’s data from the current production system into the migration sandbox. After you finish transporting the data, it is ready for testing. Then transport a slice of the current year’s posted documents into the migration sandbox. You can then move ahead with the first of the migration trials and tests. It is during the initial testing in phase zero (0) that you are likely to find data problems. When you identify these problems, you can resolve typical issues, such as corrupted data, incorrect data sources, and data posting difficulties.

Another part of the initial testing in phase zero (0) is the testing of the SAP GL configuration. If document splitting is part of the overall design, you should pay particular attention to the splitting rule configuration. If errors persist within the splitting rules during the migration weekend, the entire migration sequence will be seriously delayed. It is vital that you thoroughly test the splitting rules prior to the actual migration weekend. The more testing that takes place during phase zero (0), the smoother the actual migration will be in phase 1.

Phase 1. Of all three phases within the migration project, phase 1 is the shortest, but most intense. This is because it’s where you test the productive live data and migrate it into the SAP GL data tables. Phase 1 is the period between the end of the fiscal year and the final date of SAP GL activation.

In this phase, you migrate, validate, and test the actual productive data. The key project objective within phase 1 is to migrate live production data from the classic GL tables to the SAP GL data tables.

After migration weekend, both GL versions run in parallel until the final SAP GL activation takes place in phase 2. A key point during phase 1 is the number of processing days between the first day of the new fiscal year and the actual migration weekend. This period should be as short as possible because you need to copy and migrate all documents that are posted during this period into the SAP GL data tables. A shorter time period between the prior fiscal year-end and the migration weekend reduces the total number of documents that will be migrated.

The testing that takes place in phase 1 is similar to the testing procedures used in phase zero (0), but with one major difference: Because phase 1 takes place after the actual fiscal year end, you now can complete testing using the actual data that will be migrated. As mentioned earlier, by the start of phase 1, you should have completed, tested, and accepted the configuration of the SAP GL. Also, the preliminary testing on the various migration plans should all be compete.

As a reminder, the only data migrated from the prior fiscal year will be all open items and non-managed account balances, not individual documents from the prior year. For reporting purposes, you can still access these prior documents in their orginal source tables. The migration process copies, but does not change, the source records.

Once the fiscal year-end has passed, it is possible to transport the actual data to be migrated into the migration sandbox. After loading this data, more testing takes place regarding the migration plan configuration and the steps within the migration cockpit. The objective in this series of tests is to ensure all open items and account balances from the prior year are migrated correctly. If you find errors at this stage, you should correct them and re- test before migration weekend.

Because the accounting system is still processing documents as normal, the current year accounting documents are also available for testing. You can transport the current year documents into the migration sandbox for migration testing trials.

After you have completed all data testing and thoroughly tested the migration plan, the final step prior to migration weekend is to transport the SAP GL configuration and migration plans into the live productive systems. During this final part of phase 1, data validation and data checking continues, but within the productive system. The migration cockpit continues to provide support during this validation and checking period.

The phase 1 validation period should continue until you are completely confident that the SAP GL configuration is correct and all the migrated data balances and open items tie to the prior fiscal year records and the current year results. If at any time during phase 1 you detect errors, you can revert to the classic GL and re-migrate data to the SAP GL. In other words, you can reverse and redo the migration process as many times as required.

Phase 2. The start of phase 2 is critical because it is the date when the dual posting to both the classic GL and the SAP GL ends. After you activate the SAP GL, the system only updates the SAP GL. From that date forward, the classic GL tables are locked and frozen, and the accounting book of record is now maintained solely within the SAP GL. You can no longer return to the classic GL nor reactivate any of the migration plans.

The length of time between the start of phase 1 and the start of phase 2 is variable and depends on each migration project’s scope. Based on our experience with completed migration projects it is typical that phase 2 does not start until the late third or, in some cases, the fourth quarter of the current fiscal year. The actual time between the migration weekend and the final activation date is based on your own comfort factor with the SAP GL configuration and the migrated data.