Use this three-phased approach to upgrade to the new G/L in mySAP ERP.
MySAP ERP 2005 includes a migration tool to assist in the upgrade project.
Key Concept
By selecting the option to upgrade to SAP’s new General Ledger structure, you must understand this is a full-blown consulting project, and should be treated as such.
mySAP ERP 2005 comes with several new tools to help you migrate your financial records from the classic G/L structure to the new mySAP ERP G/L functionality. I’ll describe those tools and how they are used within the three-phase upgrade project you will need to execute. The migration tools, found in the 2005 IMG, consist of work lists, a migration plan, splitting simulation tools, and result reporting. The sidebar, “Upgrade Options,” has more information on your upgrade options by release.
When migrating to the new mySAP ERP G/L, keep in mind this important fact: The migration process is not just a plug-and-play modification that you can complete over a short period of time. This project requires several different project phases. Each phase – data migration, testing procedures, and final data certification – requires extensive planning, data verification, and final approval prior to beginning the next phase or completing the project.
You need to understand at the start the meaning and impact of two project dates – the start and finish of the migration project. The first date, the most important, is the actual date of data migration. This date must be identified very early in the project planning phase and must always be the beginning of your new/upcoming fiscal year.
The second project date is the actual date of activation for the new mySAP ERP G/L. Unlike the date of migration, this is not a fixed date, but is determined at the end of the project after you have completed all data migration, testing, and final certification.
As a standard procedure, you will most likely choose to run parallel general ledger systems initially to certify your new G/L structures. This is a suggested best practice, but understand that both the old and new G/L tables will receive the same postings during this period. Of course this has a detrimental effect on your system performance, and you should keep this period of parallel operation as short as possible. To shorten this window, it is essential that you complete a good project plan prior to the actual migration date.
Now that you understand the concept behind the dates of migration and activation, I’ll describe the different phases or steps to be followed as the migration project progresses. Basically, the G/L migration project has three phases, which are outlined in Figure 1:

Figure 1
The three phases, along with statements outlining the basic migration principles you should consider prior to beginning the migration project
- Phase one: The project plan and much of the G/L configuration are completed.
- Phase two: Much of the actual data migration takes place. This is the most complex and time-consuming phase.
Phase three: Final data certification and approval take place and the project is declared complete.
Phase 1
The first phase of the migration project takes place prior to the fiscal year-end. This is where you accomplish most of detailed project planning, organization, and configuration of both the migration tool and new G/L structure. Some major decisions at this point revolve around the structure of the new G/L. For example: What should be the G/L structure, how many ledgers are required, and should document splitting be activated? Also, SAP recommends using both Profit Center Accounting (PCA) and Segment Accounting within the new G/L. So if you are not using PCA, then part of your project plan should include time for the configuration of PCA and a review of Segment Accounting in lieu of the old Business Area concept in earlier releases. Segment Accounting offers many new features and functions previously found in Business Areas such as planning, reporting and allocations. These are just some examples of the major project planning decisions that you should consider prior to moving to the next configuration step in phase 1. Once this “blueprinting” phase is completed, you can begin the configuration of the new G/L.
The basic configuration requirements for the mySAP ERP 2005 G/L have not changed from those required for mySAP ERP 2004. The mySAP ERP IMG layout guides you step by step through the configuration for the new G/L (Figure 2).

Figure 2
Use the mySAP ERP 2005 IMG Layout for G/L implementation
As you can see in Figure 2, the first configuration step is to determine and configure the new structure of the G/L. You define the new reporting dimensions that are required by your individual reporting requirements. To do this follow the configuration steps found under the Customer Fields menu option shown in Figure 2. Next, configure the number of parallel ledgers required by your project design, and then assign the new reporting dimensions you configured earlier.
Next, define and assign the new summary tables to the new parallel ledgers –
FAGLFLEXT for mySAP ERP or FMGLFLEXT if you using the Public Sector industry solution. Other decisions required in the initial design of the new G/L regard real-time updates from Controlling, the possible use of different fiscal variants within the company codes, and use of ledger groups.
The final step of the configuration process is the decision to implement and configure document splitting (This menu option is not visible in Figure 2).
One major difference between mySAP ERP 2004 and mySAP ERP 2005 is the addition of a new G/L migration tool, which is included in the IMG (Figure 3). Find it under the mySAP ERP 2005 IMG menu option Preparation for Productive Start>Migration of Existing SAP Data.

Figure 3
New migration tools in the IMG will guide you through migration
At this point you should have completed your project blue printing and configuration of the new G/L structures and your project plans. Once these steps are complete, phase 2 can begin once the fiscal year-end closing is completed.
Part of this migration tool is the so-called migration plan. Once you have completed the basic configuration for the new G/L, you can begin the next step in project phase one: the planning and configuration of the actual migration plan. The migration plan provides the guidelines for which company codes, ledger objects, and parallel ledgers will be used in data migration. It is likely you will have to configure more that one migration plan as some constraints will prohibit only one plan for the entire project. For example, company codes running different fiscal year variants will require separate migration plans to ensure accurate data migration.
Phase 2
The next phase begins at the end of the old fiscal year, or as referred to in the plan as the date of migration. As I mentioned, the first requirement prior to beginning is completing the old fiscal year-end close.
Now you complete the configuration of the migration plan that will be used once the data migration process begins. Note that the sooner the year-end closing process is complete, the less complex the migration project will be, as you will have fewer data records to migrate. Phase 2 of the migration project consists of six distinct steps that are all located in the mySAP ERP IMG:
Step 1. Define and assign the migration plan. The major decisions at this point are whether you plan to activate document splitting and what company codes you will assign to the plan. It is possible and likely to have multiple migration plans based on company codes and differing fiscal year variants.
Step 2. Determine migration objects. The objective of this step is to build the worklists that determine the open items from the previous/old fiscal year and any new documents that have been posted after the start of the new fiscal year. Both types of financial records will be migrated into the new G/L data tables. You can complete this step individually or automatically by the use of the migration cockpit, a delivered tool. No matter which technique you use, the final result is that the open items and new documents are identified and assigned to a specific migration plan.
Step 3. Migrate open items from prior fiscal years. Now begin the actual data migration into the new G/L structure. The records that are migrated are the open items from the previous/old fiscal year, which were identified and assigned to work lists in step 2. During this step they are migrated into the new G/L totals tables (FAGLFLEXA, for example). Also, if you have decided to apply document splitting to these records, it is a requirement to employ a delivered Business Add-In (BAdI) to perform the split prior to the final posting in the new G/L data tables.
Step 4. Migrate the new documents for the current fiscal year. This step continues the data migration process, but now focuses on the open items or documents that have been posted since the start of the new/current fiscal year. For example, if your fiscal year ends on a calendar year end, these documents are the ones posted since January 1. These documents were identified and assigned to a work list and a migration plan in step 2. As in step 3, you have an opportunity to use document splitting. However, unlike step 3 in which a BAdI is required, the migration plan looks at the splitting rules established earlier during the configuration of the new G/L (if document splitting was activated).
Step 5. Carry forward the balance from the old fiscal year. The new balance sheet values are created by copying the old fiscal year-end balances into the new year’s balance sheet. Here the year-ending balance sheet balances are moved from the old totals table GLT0 into the new G/L totals tables. This sets up the new balance sheet totals for the new G/L.
Step 6. Test and evaluate the migration. The final step is checking and then rechecking the results of the data migration and possibility of document splitting. Tools are provided for this testing, as is a certification step. You have options to analyze and check the results of the migration plan as it proceeds. Data comparison tools compare different ledger balances. For example, it is very useful to compare the old G/L totals table GLT0 balance with the new totals table at the company code level. Other testing tools simulate the results of document splitting and provide easy balance adjustment procedures. Once you have checked and re-checked all the migrated data you are ready to move to the final project phase.
Phase 3
This phase includes the steps required to end the migration. You check to insure all the data work lists that were created for the migration of the prior fiscal year’s open items and the new fiscal year documents are completed and all open items and documents transferred successfully.
Note
mySAP ERP 2005 is currently in Ramp-Up status and is scheduled to be available to all SAP customers during the second quarter of 2006. If you want to install mySAP 2005 prior to the general release date, you need to apply to join the ramp-up program.
You then deactivate the G/L migration plans you used in the migration project. This is a critical step as it permanently shuts down the migration plans and data transfer. Once you close it, you can not reverse it. This step should be completed only after all testing and certification is completed.
The final step is the deactivation of future postings to the old G/L tables. Up to this time duplicate postings have been taking place in the totals tables for both the new and classic G/L tables.
Upgrade Options
Let’s discuss the some upgrade options for current SAP customers running a non-ERP release.
If you are currently using 4.6C, you should be aware that mainstream maintenance for this release ends in December 2006. You should be considering your options either to remain on 4.6C or upgrade to mySAP ERP 2005 or mySAP ERP 2004. However, you intend to install the new G/L you should choose mySAP ERP2005, which is the current ERP release.
For customers running R/3 Enterprise (4.7), the mainstream maintenance ends in March 2009, so that deadline is not as critical. However, should you wish to use the mySAP ERP new G/L, an upgrade to mySAP ERP 2005 again is the suggested option. This is the recommended option as the new G/L migration tool will not be back-ported for use in Enterprise 4.7 or mySAP ERP2004.
If you are an established mySAP ERP 2004 user, you have two options. The first is to remain on mySAP ERP 2004 and apply for upgrade assistance from SAP to migrate to the ERP G/L. The second is to upgrade to mySAP ERP 2005, where the new migration tool is available. For further guidance and help with this decision, review SAP note 812919, which explains how to apply for migration assistance from SAP for mySAP ERP2004.
All new mySAP ERP customers (ERP 2004 or ERP 2005) will find the new G/L is already activated as a default general ledger. You follow the normal configuration steps in the IMG and you will be up and running with the new G/L.
Established SAP customers who are planning to upgrade to mySAP ERP 2005 will have access to the new migration tool. However, first understand that you can upgrade to mySAP ERP 2005, continue to run the classic G/L if you choose, and then at a later date activate the new G/L by using the delivered migration tools. Whichever choice you make, the new migration tool is included with the standard mySAP ERP 2005 release.
Gary Fullmer
Gary Fullmer is currently associated with MI6 Solutions as a solution architect. Prior to MI6 Gary recently worked for SAP Labs for 13+ years. While at SAP Labs, he spent his first four years as a CO instructor developing and delivering all CO courses offered in the SAP course catalog. For the next six years, he assumed the role of a FI/CO solution manager, where he focused on interfacing with customers for CO, SEM, and FI solutions. During the remainder of his time with SAP, he worked on SAP General Ledger migration techniques, the SAP IFRS adoption model, and SAP’s enhanced financial closing, and continues to consult on these topics. His educational background includes an MBA from Rensselaer Polytechnic Institute, an MS from Utah State University, and a BS from Utah State University.
You may contact the author at gary.fullmer@MI6solutions.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.