Frank Densborn, Frank Finkbohner, Johann Gradl, Michael Roth, Michael Willinger Data Migration with SAP’ © Rheinwerk® Bonn + BostonIntroduction Data migration is hardly new to IT professionals—it's inevitable with every software update. In most cases, however, a successful upgrade doesn't resolve all your problems. Changing economic conditions and standard operating procedures within a corporation frequently lead to organizational restructuring, which, in turn, require a reorganization of the datasets in existing IT systems. Furthermore, the major issues inher- ent in data migration aren't adequately covered in the current literature, which is precisely what motivated us to write this book. In many cases, project managers underestimate the quantity of resources that data migration can tie up for the duration of a project. This frequently results in staffing bottlenecks and, therefore, financial ones as well. Data migration projects are usually carried out by program- mers (i.e., individuals with detailed technical knowledge). But, because programmers are responsible for all the applications in an installation, this merely contributes to and exacerbates the staffing problem. Keeping this programmer staffing issue in mind, you'll benefit from hav- ing data migration techniques in place that can be implemented not only by programmers, but also by consultants (i.e, those individuals without highly technical skills). Ideally, the user departments—those depart- ments that supply the data—should be able to trigger data transfers and migration projects, and model them in the IT systems. For this purpose, however, you need to have migration techniques that are easy to learn and require very little programming. Nonetheless, there will always be situations in which project require- ments are so complex that a minimal amount of programming is still necessary. Still, you should consider programming as a last resort: a recourse that should be used only when all other data migration tech- niques fail to achieve the required results. Therefore, this book will focus less on techniques for programming data migration and more on methods that enable you to avoid programming. 5 staffing bottleneck: data migration Programming-free data migrationIntroduction ‘Area of application Intended audience When a legacy system is replaced with an SAP system, SAP provides these programming-free techniques. The procedures provided aren't limited to specific applications, either; they can be used in a wide range of applications—Financials (FI), Logistics, and even SAP ERP Human Capital Management (SAP ERP HCM). Regardless of which application is used, the general procedure remains the same. Moreover, the type of data that has to be migrated is immaterial. For example, it's just as easy to migrate master data from Human Resources (HR) as it is to migrate transaction data from FI. This method is so attractive because it isn't limited merely to the tradi- tional SAP ERP applications, but also is available for some of the latest, products such as SAP S/4HANA and cloud solutions such as SAP Busi- ness ByDesign and SAP SuccessFactors. Regardless of the specific appli- cation, the procedures are so flexible that they permit the optional inte- gration of any customer-specific coding required for the migration, which makes them almost universally applicable. The availability of these methods in the individual SAP applications is discussed in the upcoming chapters. Target Audience Because custom programming should remain the exception, this book is primarily intended for individuals who don’t necessarily require pro- gramming skills themselves, but who might have to use programming, ctly or indirectly, in the course of their work. This includes SAP con- sultants hired to implement a data migration within their own organiza- tions or for an external customer, as well as project managers who need an overview of the individual methods available to make qualified deci- sions, This subject is also relevant for SAP developers who want to learn about efficient migration techniques to save time and money. The meth- ods described in this book might just make the need to write and test custom programs for data migration, so-called “throwaway programs," a thing of the past. Experience also shows that the simplicity of the data migration proce- dures enables the user departments to migrate data themselves, rounding 16out our intended audience. Consequently, the role of user departments is no longer limited to that of data supplier. With their knowledge of the data migration methods on one hand and their years of experience with the legacy IT system on the other, the user departments will most cer- tainly play an active role in data migration projects going forward. Because our intended broad audience can’t be expected to have an equivalent skill base, we've chosen the explanations and case examples in this book to be comprehensible and practical for readers both with and without detailed technical knowledge of the SAP system. To define the scope of this book, however, we must assume that readers have a basic understanding of SAP NetWeaver, Microsoft Windows, and com- mon Microsoft Office products such as Excel. Although readers will find that knowing the business context for certain issues is helpful, it's not a prerequisite for understanding the descriptions in this book Ce eee The terms data migration and data transfer are used synonymously in t book. The data source can be any legacy IT system, assuming an initial data transfer is involved, in addition to a live SAP system, if the dataset must be modified to meet organizational changes. Structure of this Book Data migration is frequently underestimated and not perceived as a fully qualified, independent subproject within the overall project. Therefore, Chapter 1 addresses the preparatory measures for data migration, which are critical to the success of any project. These measures include the selection of the project team, definition of the project schedule, and issues involving which data will be transferred and how it will be trans- lated into the SAP terminology. These processes should represent the starting point of any data migration project, regardless of which specific methods are used. Chapter 2 deals with the basics of data migration. it introduces the basic terms that are used repeatedly throughout the rest of the book and describes the steps that are involved in every data migration. The 7 Structure of this Book Prerequisites [«] Business basics Technical basicsIntroduction Plan and organize migration projects Batch input technique IDoc and ALE distribution Lsmw chapter also provides a brief overview of the data migration techniques provided by SAP. As mentioned previously, the complexity and effort involved in a data migration project are regularly underestimated. This may lead to delays in time and hence quality issues. In Chapter 3, we present how to orga- nize your data migration project by structuring it. We describe the d ferent types of data migration projects, the phases of such projects and the tasks that occur in the different phases with the help of practical examples. At the end of this chapter, we provide you with useful notes for planning and effort estimation of data migration projects. After Chapter 2 and Chapter 3 have familiarized you with the basics, Chapter 4 introduces the conventional method for migrating data: the batch input technique. In addition to a general introduction, this chapter introduces both the standard batch input programs for data migration supplied by SAP and custom batch input programs that are relatively easy to write. Chapter 5 introduces the intermediate document (IDoo) and Application Link Enabling (ALE) technique that is widely used as interface technol- ogy and foundation for Legacy System Migration Workbench (LSMW), which is discussed in Chapter 6 and Chapter 7, and the Rapid Data Migration content based on SAP Data Services, which is introduced in Chapter 8. This chapter also describes the use of the Data Transfer Work- bench (sometimes called the DX Workbench) tool, which comes with helpful accessories and provides features for project management and data migration tests, It also comes with an editor to manipulate test data and create IDoc or Business Application Programming Interface (BAPI) structures. You'll certainly appreciate this versatile tool from the data migration portfolio because you'll be able to apply it in various situa- tions in a very helpful way. For cases in which the requirements of a data migration prove to be too complex for the batch input procedure, the Legacy System Migration Workbench (LSMW) introduced in Chapter 6 is a much more flexible tool. The LSMW lets you transfer data from non-SAP systems to an SAP system with minimal programming required. This tool is the right choice whenever the structure of the legacy data differs significantly 18from the structure of the data in the SAP system—making data conver- sion inevitable—or when the legacy data has to be augmented with data already in the SAP system. ‘A deeper look at the LSMW is provided in Chapter 7 in which we use usage examples to explain how LSMW functions are used to solve more complex data migration. The chapter is intended to be used by experts and consultants to solve their complex use cases with the help of the LSMW. Although the emphasis of this book is to avoid programming in your data migration, there are use cases where it's necessary to program small pieces of code. In this chapter, we illustrate the structure of the LSMW's generated conversion programs. You'll learn how to solve cer- tain use cases with the help of small pieces of practical program code within the LSMW's field mapping. In Chapter 8, we'll explain how you can migrate your data using an extraction, transformation, and loading (ETL) tool with preconfigured content, With this Rapid Data Migration approach, data quality and data validation will be the first priority. The key is standardized and engi- neered content of predefined SAP Best Practices as the foundation of a new approach led by standard tools and best-practices migration meth- odology. We'll introduce both the architecture and the process, as well as provide detailed guidance for expert users and enhancing the content. Chapter 9 will introduce you to data migration into SAP Business ByDesign and SAP Cloud for Customer. Based on a sample, we'll guide you through the central migration steps in these SAP cloud solutions, focusing on value mapping, import simulations, and the editing features to adjust identified data errors. Both approaches will be covered, the migration from predefined migration templates as well as from comma- separated values (CSV) files using field mapping. A separate section will address the migration of accounting transactional data and the posting preview features. Expert tips on parallelization and reconciliation com- plete this chapter. If you've read through to Chapter 9 and still think you'll have to resort to programming for your own data migration, Chapter 10 utilizes numerous examples to change your mind. The examples in this chapter show you how the migration dataset can be prepared with Microsoft 19 Structure of this Book LSMW for experts Rapid Data ‘Migration with ‘SAP Data Services SAP Business ByDesign and ‘SAP Cloud for CustomerIntroduction Assessment of data migration techniques Advanced Topics and SAP S/4HANA Appendix Icons key b>] Excel or Microsoft Access, for example, using the described program- ming-free method instead of a custom-written program to migrate the data to the SAP system. After the individual data migration methods have been introduced, Chapter 11 looks at each of these methods with a critical eye. In partic ular, this chapter describes the advantages and disadvantages of each technique and attempts to pinpoint the best procedure for a given situ- ation. Chapter 12 informs you of recent developments and areas related to data migration. This chapter takes a closer look at the subject of data extraction from existing SAP systems using tools and products such as SAP Landscape Transformation (SAP LT), Migration Workbench (MWB), and SAP Test Data Migration Server (SAP TDMS). In addition, we describe database migration (DB migration) and the different migration paths to SAP's new business suite called SAP S/4HANA. As mentioned previously, datasets within existing IT systems must also be adapted to changing framework conditions over the course of time. The Appendix provides you with a module-specific overview of selected SAP tables that typically must be processed during a restructuring. Familiarity with these tables will help you find the relevant data in the system via accelerating the overall process. You can download the Appendix from the book's web page (www.sap-press.com/4019). This book is structured to allow you to jump directly to the specific chapter that interests you without having to read all the previous chap- ters (see Figure 1). Alternatively, this book is also intended as a compre- hensive project manual for data migration that can be read sequentially. After you've read itin its entirety, you'll be able to plan, judge, and exe- cute your own migration projects. Detailed case examples, illustrated with numerous screenshots, will help you achieve this goal Throughout the book, icons will alert you to special tips, warnings, notes, and examples. Note This icon helps expand on a topic, either by presenting you with the extra information or by providing you with links to additional resources. 20New to This Edition Hints and Tips 4] This icon highlight tips that will make your work easier or helps you find shortcuts or workarounds. Warning ] This icon helps you avoid common mistakes or alerts you to actions that once done, cannot be undone. Examples fed This icon explains and gives more information on a current topic based ‘on practical examples. 1 Business Basis for Migrating Data to SAP. 2 Technical Basics for Migrating Data to SAP 55 IDoc and ALE ution Rapid Data Migration Peso with SAP Data Services 6 Legacy System gration Workbench 9 Data Migration to SAP Business ByDesign and SAP Cloud for Customer 7 Legacy Syster Migration ‘Worktrench for Experts 40 Techniques for Avoid “11 Assement of Data 12 Outlook and Related Ing Programming, ‘Migration Techniques ‘reas Figure 1 Book Structure and Dependencies between Chapters New to This Edition For this third edition, the entire book was profoundly revised and, Changes and wherever necessary, corrected or rendered more precisely. The texts, enhancements in figures, and terminology have been adapted to the current releases. te tre ed Chapter 3, “Plan and Organize Your Data Migration Project"; Chapter 5, 2Introduction "IDoc and ALE Distribution"; Chapter 8, "Rapid Data Migration with SAP Data Services"; and Chapter 9, "Data Migration to SAP Business ByDesign and SAP Cloud for Customers” were added. The LSMW chap- ter was divided into a chapter on the basics (Chapter 6) and a chapter for the experts (Chapter 7) with a lot of added practical examples. Focus on SAP This book predominantly describes techniques and methods used in the ERP6.0 current SAP ERP 6.0 release, independent of the installed enhancement packages version. Figure 2 shows an overview of the SAP ERP compo- nents within the SAP Business Suite portfolio. SAP CRM Customer relationship management SAP SRM SAP SCM. Supplier ‘supply relationship chain management ‘management Figure 2 SAP Business Suites, SAP ERP, SAP ECC, and SAP NetWeaver, We hope that you'll enjoy reading this book and find it helpful in your data migration projects, endeavors, and responsibilities. Frank Densborn, Frank Finkbohner, Johann Gradl, Michael Roth, and Michael Willinger 2For a data migration to deliver the desired results, it should be discussed at an early stage. The data migration also must qual- ify as a subproject within the overall implementation project. Lastly, sufficient project resources must be reserved for migra- tion activities. 41 Business Basics for Migrating Data to SAP This chapter provides information regarding the business aspects of a data migration. For a data migration to be successful, you must not only ensure the technical correctness of the data migration itself, but also be able to guarantee the quality of the data post-migration. TI ‘you and other stakeholders to make the right decisions after migration. In this chapter, we will make the case for data migration as its own sub- project, walk through some of the preliminary considerations for a data migration project, and then give an overview of the essential tasks of a migration project. We provide several accounting examples to help sup- port and provide context for these important steps. will allow 14 Data Migration as a Subproject Frequently, data migration doesn’t get the attention it deserves. All too often, project managers fail to realize that, depending on the project scope, data migration can tie up staffing resources and financial resources as well. Staffing bottlenecks occur whenever the data migra- tion technique restricts the migration activities to a select group of indi- viduals. Because custom data transfer programs are often used, it becomes readily apparent that a lack of resources among programmers is the primary cause of the bottlenecks. As mentioned in the Introduc- tion, the objective of this book is to introduce migration techniques that 23 Staffing bottleneck1 | Business Basics for Migrating Data to SAP Foundation for business processes Data migration as an iterative process are easy to learn, ensure data security, and, ideally, don't require any custom programming, Consequently, data migration is no longer the sole responsibility of programmers. Because individuals who don't pos- sess complex programming skills can be involved in the migration pro- cess as well, the likelihood of staffing bottlenecks occurring is signifi- cantly reduced. The need to manage limited project resources isn't the only factor that makes data migration an independent subproject within an overall implementation project. Another aspect that you shouldn't underesti- mate is the information conveyed within the migrated data, that is, the data quality. For example, it's indisputable that the open items in the legacy system have to correspond to those in SAP—both individually and cumulatively —to ensure data consistency between the systems. This alone is far from sufficient, however. Because data migration is the foun- dation for all subsequent business processes in SAP, you must also migrate information that may not appear to be relevant, but that may be the control data that ensures smooth handling of downstream processes. Therefore, it's not enough to simply ensure that the migrated data is quantitatively complete. You must also investigate whether the migrated data can handle the operative transactions in the new system, and whether it has the necessary information for the decision-making pro- cesses. In the open items example, this means that in addition to verify- ing that the amounts are correct, you must also ensure that the due dates are calculated properly because they can have a direct impact on an enterprise's liquidity planning. Missing or incorrect information can steer decision-making processes in an entirely unintended direction. For this reason, we recommend that you design your data migration project as an iterative process. This means you can begin testing the data migration as soon as you've extracted the first data from the legacy sys- tem and Customizing in SAP permits the data migration (we'll address the latter in detail in Chapter 3). Based on the initial results, you can then check in a subsequent step whether all the information required for smooth handling of the downstream processes is available. This involves comprehensive system testing and potential changes to the Customizing configuration. If information is missing, you must first determine where to obtain it and then repeat the data migration process 24Preliminary Considerations until you achieve the results that you want. Note that you can never exe- cute the data migration or test the business processes in isolation; these two tasks are inextricably woven together. Again, this last aspect emphasizes the importance of data migration in an overall implementation process. In this context, the individuals respon- sible for the data migration are well advised to deal with the processes in the legacy system early on and to examine how these processes can be mapped in SAP, especially if a business reengineering is required when the new system is being implemented. Because no one knows the legacy IT system better than the user department staff, they should be involved in the processes from the start to prevent staffing bottlenecks in this area as well. With this approach, the user department staff will become famil- iar with the philosophy of the SAP system step by step and will be better able to determine what data must be provided to ensure a smooth sys- tem migration. 4.2. Preliminary Considerations At the start of the project, you can determine the preliminary consider- ations that will shape the subsequent migration project based on the leg- acy system, without requiring detailed knowledge of the SAP system These considerations include defining the dataset for the migration, identifying legacy data that may not need to be migrated, steps you can take to reduce the volume of data must migrate, preparation for data extraction, and some special considerations regarding accounting data, 12.4 Defining the Dataset for Migration The data to be migrated can be divided into master data and transaction data, as described in the following subsections. Master Data ‘Master data involves information that you always need for the same pur- pose, and it remains unchanged over a long period of time. Of course, it makes sense to migrate only the master data that is actually used. Dor mant data (see Section 1.2.2), that is, data without any operative use, 25 ‘system ‘comprehension Relevance 121 | Business Basics for Migrating Data to SAP Line items or balances Analyzing the legacy dataset Relevance of the legacy dataset should be flagged as such in the legacy system to exclude it from the migration process. Transaction Data Transaction data has a short life cycle and can be assigned to specific master data. This is sometimes also referred to as “posting documents." In this case, you must clarify just how detailed of a legacy system history should be mapped in SAP. Specifically, you must decide whether you want to migrate the individual posting documents, or line items, or only need the accumulated, updated values, namely, the balances. If you decide to migrate the line items, you must determine the number of items in the past fiscal years that you want to migrate and which role the cleared items (for information purposes only) have to perform. If you decide to migrate the balances, the legacy system must remain available to provide detailed information, at least during the transition phase. Past experience shows that most migration projects use a combination of line items and balances. Many managers decide to migrate all the line items for customers and vendors and use them to continue the business processes in SAP. Conversely, the line items aren't integral to balance sheet accounts and income statement accounts. The specific situation determines which data has to be migrated. 4.2.2 Identifying Dormant Data You should always think of a change to a new IT system as an opportu- nity to examine your legacy data and eliminate data that, while still stored in the legacy system, has no operative use now or in the future. Your time investment in this task will more than pay off because it will ensure a consistent, orderly data basis in the new system. In addition, this procedure can significantly reduce the data volume for migration and, therefore, lessen the overall time required for the data transfer. ‘The issue here is how to identify this dormant data. The following exam- ples describe several methods. ‘Master Data Example If you can analyze which master data hasn't been used actively for a lon- ger period (¢.g., two years), this analysis can be the starting point for 26Preliminary Considerations | 1.2 deciding whether the identified data will be needed in the future. If not, you can flag the data as being not relevant for migration, thereby exclud- ing it from further migration steps. You'll frequently encounter situations in which identical master data exists several times in a legacy system. While this data is saved under different identification numbers, their contents are identical, or nearly so, In this case, an analysis can help you discover whether this situation exists in your system. If it does, you can flag the redundant data as being not relevant to exclude it from further migration steps. The situation becomes somewhat more complex when transactions are based on the redundant master data. In such situations, you'll have to change the identified postings in the legacy system or auxiliary external system (such as Microsoft Excel) before you can eliminate the redundant master data. If you don't do this, migrating the transaction data will cause errors because the transaction data won't have the corresponding master data in the new system Regardless of the issues that we just addressed, the affected user depart- ments should always investigate whether the current operative master data will continue to be used in the same manner in the new system, or whether the history should start anew with the successor system. Classic examples include charts of accounts that have grown over time and yet consist of many individual accounts. In this case, you must ask yourself whether all the master data are really needed, or whether it would be more expedient for information and control purposes to consolidate the master data and reduce it to a more manageable amount. If you decide on the latter, posting changes will be required. Transaction Data Example You may discover that your legacy system contains transactions that the SAP system can't identify as such. Such cases involve postings with zero values. To avoid problems with the subsequent migration from the start, you should search your legacy dataset for such transactions and elimi- nate any such items found. You must consider what you want to do with transactions that can be allocated to the same master data record, but which balance to zero 7 Redundant legacy data Grouping master data Zero values Balancing items1 | Business Basics for Migrating Data to SAP Close processes Payment before the due date How to extract the data when added together. Is there a reason for this situation that justifies identifying the items separately, or has someone merely forgotten to clear the items in the legacy system? Analysis in the legacy system will help you answer these questions. If the analysis indicates that balancing the items would be beneficial, you can do so directly in the legacy sys- tem or in an auxiliary system. This step will have a direct impact on the migration data volume. 1.2.3. Measures for Reducing the Data Volume The question as to how detailed the duplication of the legacy system's history will be in the successor system has a major influence on the data volume. Even if you decide to migrate the line items, several measures can help you reduce the numbers of these items prior to migration: » If processes can be closed, they shouldn’t be set to a status such as OPEN or PARTIALLY COMPLETE; instead, set these processes to Com- PLETED. Depending on the application, items with this status may be excluded from the data migration. > If your economic situation and company policy permit it, you might consider paying outstanding vendor invoices before executing the data migration to take advantage of cash discounts. Not only will this shrink the volume of data to be migrated (assuming paid items aren't relevant for the migration), but it will also help to reduce your expenses. > Another possible approach is to adjust your payment pattern to keep credit memos to a minimum. 1.2.4 Preparatory Measures for Extracting the Legacy Data Because the user departments or other individuals responsible for extracting the legacy data aren't sufficiently familiar with the processes in the SAP system, it makes little sense for them to provide an initial data extract for testing the legacy data transfer in this early project phase. Nonetheless, at the start of the project, you should determine whether the legacy system can collect all the information contained in the master and transaction data and export it to one or more files. One significant question to ask yourself here is whether the legacy system 28Preliminary Considerations | 1.2 has standard functions for creating such data extracts or whether custom programming will be required. In the latter case, you must clarify whether in-house expertise is available or whether you'll have to bring in external consulting resources, which will have to be scheduled accordingly. 1.2.5 Addendum: Accounting Considerations If you want to migrate transaction data, you must deal directly with accounting issues that have to be solved prior to the data migration. We'll present this rather dry and sometimes menacing subject—and the extent to which it affects the data migration—in such a way that makes it easy to comprehend. The following information will help you better understand Chapter 4, which is dedicated to the migration of transaction data. Here, the main issue is how the transaction data, such as open credit items, will be migrated in SAP. It's clear that the gross amounts from invoices and credit memos will have to be identified in the credit and debit columns of the correspond- ing vendor accounts, but what about the corresponding offsetting post- ings? One option in this case is to configure a migration account in the SAP General Ledger (G/L) that transfers only the open items and receives all the offsetting entries from the data migration. To document the special status of this account, the account number 9xxxxx is usually selected. The following example illustrates this option. Vendor 1 has two open invoices (I) in the amounts of $100 and $200, and it has a credit memo (C) in the amount of $50. Vendor 2 has an out- standing invoice in the amount of $150. From an accounting perspective, the vendor accounts look like Table 1.1. Debit Credit Debit Credit 50 1100 Balance 150 1150 Balance 250 1200 Table 4.1 Transaction Data from Vendor 1 and Vendor 2 29 ‘Migration account Example 11 | Business Basics for Migrating Data to SAP Attributes of the migration account Reconciliation accounts The migration account looks like Table 1.2. Credit c50 Balance 400 Table 1.2 Transaction Data from Vendor 1 and Vendor 2 on the Migration Account As this example shows, the balance of the migration account is the exact, sum of the balances of the vendor accounts to be migrated. This means the migration account is ideal for an initial comparison of the totals between the legacy system and the SAP system. If the totals are identical in both systems, you can simply check a random sampling of the vendor accounts to confirm their accuracy. In most cases, the migration account isn't assigned to a balance sheet item, which means it's identified as a nonassigned account under the bot- tom line. If you migrate your data at the start of a fiscal year and use only ‘one migration account for the vendor data, open sales items, and figures from the remaining balance sheet accounts, this account will balance to zero, assuming the data migration runs without errors. In this case, you can consider the migration account as an account that mirrors all the post- ings to be transferred from all accounts. You can draw parallels to an ‘opening balance sheet account, which mirrors all the opening balances of the opening balance sheet and also balances to zero. In contrast to an ‘opening balance sheet account, which contains only opening balances (one balance per account), the migration account can also explain the rea- son for these balances, as it lists the corresponding line items. But, what does “transferring the remaining balance sheet accounts* mean? These are all the accounts listed in the financial statements, pro- vided they don't represent reconciliation accounts. Here, a reconciliation account is a G/L account that records the transactions from subledger accounting, such as accounts payable and accounts receivable. You can't post directly to the reconciliation accounts, Instead, they receive all the 30Preliminary Considerations | 1.2 values automatically as soon as a corresponding posting is created in the subledger. Generally, several accounts from subledger accounting—sev- eral vendor accounts, for example—point to a shared reconci account. This identifies the subledger transactions in G/L accounting for the financial statements. Because the corresponding vendors and cus- tomers are posted to directly during the migration of the vendor/cus- tomer open items—that is, the posting takes place in the subledgers— the integration of the G/L and the subledgers indicates that no further postings to the reconciliation account are needed. Therefore, you can exclude the reconciliation accounts entirely from the data migration process. tion ‘When asset values must be migrated, the situation differs. Here, integra- tion of the G/L and the asset subledger isn't ensured for the duration of the legacy data transfer. Therefore, after the data migration, you must manually post to the reconciliation accounts in SAP Financial Asset Man- agement (FI-AM). Because direct postings to reconciliation accounts aren't supported in the application menu for Financials (FD), however, the corresponding functions are located in Customizing for Asset Man- agement. Like the migration of balance sheet accounts, the migration of the profit and loss (P&L) accounts must also be clarified. If you migrate the data at the start of a fiscal year, the decision is clear. Because all the P&L accounts transfer their balances to the retained earnings account, which you define in Customizing for FI, at the end of the fiscal year, they all have a zero balance at the start of the new fiscal year. This, in turn, means they don’t contain any transactions from the current year and therefore can be excluded from the data migration. If you migrate your data in midyear, however, transactions may have taken place in the P&L accounts and, therefore, will have to be migrated. In the latter case, note that the P&L accounts haven't yet passed their postings on to the retained earnings accounts, which is identified in the financial state- ments. This means the assets and liabilities aren't directly equal; the profit or loss currently in the P&L accounts still must be added. Thus, the migration account will have a balance after migration of the balance sheet accounts, which corresponds exactly to the amount of profit or loss. The following example illustrates this situation. x Migrating assets Migrating P&L accountsBusiness Basics for Migrating Data to SAP €xample2 Fixed assets (FA) show a balance in the amount of $1,000, and current assets (CA) show a balance in the amount of $500. In addition, the open- ing balance of stockholders’ equity (SE) was $500. The P&L account now shows a profit (PROF) of $500 that hasn't yet been transferred to the retained earnings account, Therefore, this amount isn’t allocated to SE yet in the financial statements. If you take into account the current pay- ables (PAYB) in the amount of $500, you obtain the results seen in Table 1.3 and Table 1.4. eee Assets Liabilities FA 1.000 SE 500 A500 PAYB 500 Table 4.3 Financial Statement after Migration of Balance Sheet Accounts in Midyear Profit and Loss Statement Debit Credit ERTR 500 Table 1.4 Profit & Loss Statement after Migration of P&L Accounts in Midyear Note that the value for the payables is made up of a large number of G/L accounts and line items, for example, and also contains the open credit items, represented by the vendor reconciliation account. As just described, all of these line items will result in an appropriate offsetting posting in the migration account. To presenta simple, easy-to-follow financial statement, however, we've chosen to omit a breakdown of FA, CA, SE, and PAYB into G/L accounts and their line items. We used the same strategy with the iden- tification of the profit in the P&L statement. Given these basic assump- tions, and after migrating the balance sheet accounts (including subled- gers), the migration account looks like Table 1.5. Debit Credit SE 500 FA 1.000 Table 4.5 Migration Account after Migration of Balance Sheet Accounts in Midyear 2Preliminary Considerations | 1.2 iinnncer PAYB 500 A500 Balance 500 Table 1.5 Migration Account after Migration of Balance Sheet Accounts in Midyear (Cont.) Therefore, the balance in the migration account, after the migration of the balance sheet accounts, corresponds exactly to the amount of the profit or loss—the amount of revenues in the preceding example—that has to be migrated. After the revenues have also been migrated to SAP, the migration account looks like Table 1.6. [imine Debit Credit SE 500 FA 1.000 PAYB 500 cA 500 PROF 500 Table 1.6 Migration Account after Migration of Balance Sheet Accounts and P&L Accounts in Midyear To summarize, the following rule applies. After a successful data trans- fer, the migration account must always have a balance of zero, regardless of whether the data migration was performed at the start of a fiscal year or in midyear. If the data is migrated at the start of a fiscal year, the migration account doesn't have any P&L components and, therefore, shows only the transactions in the subledgers and other balance sheet accounts. If the data is migrated in midyear, however, the migration account may also contain P&L components. It should also be apparent that the migration account always represents all the transactions to be migrated as a mirror image of the postings to the G/L accounts or the postings in the subledgers. Alternatively, you can work with multiple migration accounts. For example, you can have one migration account for vendors, another migration account for customers, and still another for fixed assets as well as other balance sheet and P&L accounts. In this constellation of accounts, the balances of the different migration accounts will add up to Balance of migration account always zero ‘One or more migration accounts1 Business Basics for Migrating Data to SAP Posting keys Reference to Example 1 zero after an error-free migration. There is no general recommendation as to how many migration accounts you should use; it depends primarily on your personal preferences. It's definitely not advisable, however, to define vast numbers of migration accounts to make it easier to localize errors later on. You can achieve the same results if you use only one migration account but different document types (i.e., depending on the situation) that you can then select for the migration account. After the question of the data transfer account has been clarified, you can concentrate on the next subject, which is directly related to the migration of the accounting documents, namely, the posting key. This is a two-digit numeric key that controls the recording of document items. Among other things, the posting key defines the account type, that is, whether a vendor account, a customer account, a G/L. account posting, or a posting from FI-AM is involved. The posting key also indicates whether the specified account is posted to in credit or in debit. Posting keys are used whenever you use documents for posting, such as open credit items, in the standard SAP transactions for document entry, espe- cially Transaction FBO1. Returning to Example 1 (see Table 1.1 and Table 1.2), typically, a data transfer document consists of two items. In addition to the vendor accounts (vendor 1, vendor 2), G/L accounts (migration account) are included. Debit postings to G/L accounts must be assigned posting key 40 (PK 40, in the example); credit postings to G/L accounts must be assigned posting key 50 (PK 50). You can differentiate further between debit and credit postings to vendor accounts by choosing from different debit and credit posting keys. We recommend using the standard SAP posting keys for vendor invoices (31) and vendor credit memos (21), which results in the figures seen in Table 1.7. PK 40 ‘Migration Account 100 Pk 31 Vendor 1 100) PK 21 Vendor 1 50 Pk 50 ‘Migration Account 50(-) Table 17 Recommended Posting Keys for Vendor Migration 34‘The Data Migration Process from the Project Perspective | 1.3 In the process, the SAP system assigns a minus sign (-) to every credit posting, independently of the account type, so the document items always balance to zero when they are entered correctly. Therefore, the posting key controls whether an entered amount is interpreted as posi- tive or negative: Lastly, you must transfer customer open items and G/L account postings in a similar manner (see Table 1.8). PK 01 Customer 1 100 PK 50 ‘Migration Account 100) Customer Credit Memo PK 40 Migration Account 50 PK 1A Customer 4 50) G/L Account Posting in Credit PK 40 ‘Migration Account 200 PK 50 GL Account, 200) G/L Account Posting in Debit Bs 40 GL Account, 100 Bs 50 Obernahmekonto 100) Table 4.8 Recommended Posting Keys for Customer and G/L Account Migration 14.3 The Data Migration Process from the Project Perspective After you've finalized the considerations discussed in Section 1.2, you can begin to prepare for the actual data migration. In the following sec- tions we will walk you through the main tasks of a data migration proj- ect. 4.3.1 Basic Customizing First, Customizing in SAP must have progressed enough to enable execu- tion of the basic processes that follow the data migration. For example, it 35 Posting keys for vendors Posting keys for customers.1 | Business Basics for Migrating Data to SAP Theoretical and system presentations Paradigm shift Organization follows software doesn't make any sense to transfer open items if no payment terms have been previously defined in Customizing, which clearly indicates the due dates of the open items. In this example, the payment run is a follow-up process that will provide incorrect results if no exact due dates are avail- able. 1.3.2. System Presentations in SAP Before they can provide the files with the necessary data from the legacy system, the involved user departments have to become familiar with and understand the process flows in the SAP system. One way to impart this knowledge is to give theoretical presentations of the SAP structures, their mutual dependencies, and the data flow that these structures create in an integrated system. This theoretical background makes it easier to understand and classify subsequent presentations in a live or simulated SAP system. Throughout all these presentations, you should always ensure that the appropriate individuals are involved to enable them to ask the right questions. Ideally, after this initial meeting, the participating user departments will already be able to roughly determine which data has to be extracted from the legacy system to achieve the desired results in SAP. 1 3 Business Reengineering A far more difficult situation arises when the SAP system and the legacy system are based on different logic, and, therefore, the legacy system data can't be migrated directly to SAP. In this situation, the data must be processed prior to the transfer to enable its subsequent use in SAP. This process can be extremely time-consuming and, therefore, should not be underestimated. The SAP system often requires information to map the business processes—called required entry flelds—that doesn't necessarily exist in this form in the legacy system. Conversely, the legacy system may contain information in its data records that SAP doesn't require due to differing application logic and possible organizational structures. The system knowledge described in Section 1.3.2 is particularly import- ant in this framework because, for the participating user departments, it’s the foundation on which they can restructure and redesign their 36‘The Data Migration Process from the Project Perspective | 1.3 business processes. Therefore, the organization and data structures fol- low the demands of the new software. Because this business reengineer- ing can take on extremely complex dimensions, you may once again want to discuss the extent to which you want to model the legacy sys- tem’s history in the successor system (see Section 1.2.1). 1.3.4 Simulating the Data Migration After you've held the initial SAP system presentations, and the user departments understand the logic of the SAP system, you can intensify your focus on the activities associated with the data migration itself: > Identifying the enterprise resource planning transactions that you want to use to migrate the legacy data to SAP. » Running these identified transactions manually in SAP with test data from the legacy system, and note which fields are required. There may be required entry fields that have no corresponding data fields in the legacy system. After the SAP transactions and the fields to be maintained are known, you can continue with the mapping phase. 4.3.5 | Mapping (Field Matching) The field names in the legacy system agree with the corresponding ter- minology in the SAP system only in the rarest of cases. If different nam- ing conventions are used, the respective names must be recorded and assigned accordingly—theoretically at first—on a piece of paper. This procedure is usually referred to as mapping. In the simplest case, the field names will be identical, which means the following equation applies: Field name (legacy system) = Field name (SAP) If the fields differ merely in their terminology but not their content, this relationship still holds true. If different designs are involved, however, the fields from the legacy sys- tem must be transformed upfront—because SAP doesn’t recognize them 7 ‘Mapping 1:1 relationships ‘Transformations1 Business Basics for Migrating Data to SAP Example Required entry fields in their source format—and then assigned to the corresponding fields in SAP. The legacy system doesn't necessarily have to work with posting keys, which are control parameters from FI that control the account type, among other things, and determine whether a debit posting or a credit posting is involved. Similarly, you may discover that the legacy system uses a different logic to categorize its postings. In such cases, the individual fields of the legacy system, which control whether the post- ings to the respective accounts are listed under credits or debits, must be transformed to the appropriate posting keys in keeping with the SAP ERP philosophy. In general, the following applies: Field name(s) (legacy system) —> Transformation —> Field name(s) (SAP) First, consider the example of the posting keys. If you assume that the legacy system generally flags invoices with *I" and credit memos with *C," the transformation process detailed in Table 1.9 is required. crea eon ecu Exerc Vendor invoices and 31 Credit Memos c 2 Customer Invoices and 1 o Credit Memos c " Table 1.9 Field Mapping between a Legacy System and SAP System for the Field " posting key’ Ifa field is mandatory in SAP (required entry field), but the legacy system doesn'thave an equivalent field, the existing structures in the legacy sys- tem will have to be reworked —in an auxiliary system such as Microsoft Excel, for example—and adapted to the requirements of the new system landscape (see Section 1.3.3). Alternatively, you can set the field to a constant (solely for the data migration) or change the field to an optional entry field in Customizing At the end of this step, every SAP field that is required for data migra- tion must be assigned a corresponding field from the legacy system, cither by direct assignment or through a transformation process. 38‘The Data Migration Process from the Project Perspective | 1.3 4.3.6 Data Extraction from the Legacy System After the legacy system fields have been mapped to the corresponding SAP fields, at least theoretically (see Section 1.3.5), the next step involves extracting all the flelds that are required to madel the business processes in SAP and their contents from the legacy system. When extracting the data from the legacy system, you should ensure that the data is provided in one or more text files; this makes it much easier to postprocess the data manually with a spreadsheet program (see n 1.3.7). You can also use SAP DATA Services for extracting data (see Chapter 8) Sect 1.3.7, Manual Postprocessing of the Extracted Data Only rarely will the field mapping between the legacy system and the SAP system deliver results that don't require manual postprocessing of the extracted data. In most cases, the data records must be adapted or transformed—due to a changed system landscape or business reengi- neering—to enable their processing in the SAP system. Therefore, your objective in this manual postprocessing is to create a file that the SAP system can process without any further transformations or adjustments. This file is the result of the mapping performed in a previ- ous step. The elimination of data that is no longer needed is also part of this process (see Section 1.2.2) Conventional spreadsheet programs such as Microsoft Excel will help you achieve this objective via their various calculation, filtering, and replacement functions. If your intention is to avoid programming, you must ensure that this step is properly addressed within the process chain. As we mentioned previously, because one of our main goals in writing this book is to show you how to enable data migration without using custom programming, in Chapter 10, we describe several ways in which you can format your dataset in advance to avoid time-intensive programming during the subsequent migration phase. 13.8 Selecting a Data Migration Technique When selecting the migration techniques, you must weigh your data security needs against the speed with which the data has to be migrated 39 Text files Using spreadsheet programs ‘Speed versus security1 | Business Basics for Migrating Data to SAP Upload according to migration technique Troubleshooting fy] Dependencies and order of activities to the SAP system. You should be aware that speed comes at the expense of data security; it's almost impossible to achieve both goals simultane- ously. After you learn about the individual methods for data migration, we'll assess the various techniques and describe which procedures are opti- mal for certain situations in Chapter 11. 4.3.9 Uploading the Data in SAP ‘The data upload to SAP is a strictly technical process that you perform in accordance with the selected migration procedure (see Section 1.3.8). Chapter 4 through Chapter 7 describe which preparation steps are required in SAP. Problems that occur during the data upload are usually the direct result of an insufficient or erroneous data basis (see Section 1.3.7). If the upload process terminates, you'll have to analyze the data basis in depth, adjust it accordingly, and then repeat the upload. Any changes made to the database in the interim will have to be undone to avoid falsifying the results, which is yet another reason for you to pay particular attention to the activities described in Section 1.3.7. PER eed Unfortunately, not all the application areas in the SAP system provide func- tions for deleting specific data. In such cases, you'll have to back up your data prior to migration and restore the backup if your initial migration fails. To be thorough, you should take into account many dependencies during the migration. These dependencies require you to perform cer- tain activities in a specific order, for example: > Master data before transaction data » G/L before subledger (e.g., reconciliation account before vendor) » Purchase orders before goods receipt postings > Material master data before bills of material (BOMs) 40‘The Data Migration Process from the Project Perspective | 1.3 1.3.10 Testing the Business Processes in SAP After you've transferred your dataset to the SAP system—without pro- gram terminations—you must ensure that the migrated data is quantita tively complete. If transaction data is involved, you can compare the totals between the data in the upload file and the results in SAP for an initial assessment. If no variances are detected, you can then analyze several random data records to ensure that all the fields in SAP have been filled as expected according to the mapping (see Section 1.3.5). If differences occur between the expected and actual results, however, we recommend localizing the difference through a targeted analysis in SAP. This will help you determine whether the data basis was insufficient or whether the problems are due to a systematic error related to the selected migration procedure. Depending on the result, you'll have to analyze the data basis or the selected data migration procedure again and change it if necessary. However, verifying that the data is quantitatively complete won't suf- fice. You must ensure that the data contains all the information required to model the subsequent business processes in SAP, To do so, the migrated data must be processed further in the SAP system because this data is used as the foundation for testing the business processes. As you can see, you can't look at a data migration in isolation; you should always view it in the context of system tests as well. If the data basis fails this system test because required information is missing, you'll have to migrate additional fields from the legacy system to SAP. Consequently, you'll have to revise the mapping that you devel- oped in Section 1.3.5. This new information then serves as the founda- tion for extracting and postprocessing the data again, as described in Section 1.3.6 and Section 1.3.7, and then importing it into SAP (after you've deleted the old, incorrect dataset). You have to continue this iter- ative process until you achieve the desired results in SAP. Figure 1.1 provides an overview of the full data migration process, as described in this section. 4 Quantitative completeness Testing the business processes Iterative process4 Business Basics for Migrating Data to SAP Seem pert Simulate data migration ‘mapping Extract legacy data Postprocess legacy data Select migration technique Upload SAP Testing Figure 1.1 Data Migration Process Flow 1.4 Summary This chapter demonstrated that the business-related aspects in the con- text of a data migration are even more important than the specific tech- nique to migrate data. Even if the data migration works properly from a technical point of view, this is no guarantee that the data quality of the migrated data is good as well. You need to be focused not only on the technical aspects of a data migration—described in detail in subsequent chapters—but also on the relevant data to be migrated into the SAP sys- tem to make the right decisions in the daily business processes.In addition to the business aspects, data migration naturally comprises technical aspects that must be considered. To familiar- ize you with the technical side, this chapter defines important terms and explains the structure of the underlying processes. 2 Technical Basics for Migrating Data to SAP Data migration, in its simplest form, is the transfer of business data from one system to another system in an organized way. However, it is also comprised of a number of technical aspects: exporting data from the leg- acy system into transportable units, such as files, converting data—both technically and semantically —and importing the data into the target sys- tem in a way that they can be used in business processes. In this chapter, we will start by providing you with the terminology you will need to discuss your data migration. Then, we will walk you through the techni- cal steps common to most data migrations and give you an overview of the technical procedures for a data migration, 2.1 Basic Terminology The following terms will appear throughout this book and are important for understanding data migration processes: » Data migration, migration The term data migration refers to the transfer of business data (master and transaction data) from any application system to an SAP system. The term migration is used as a synonym. Please note that this term is also used in other contexts, such as migrating from one technical platform to another; however, this isn’t the intended meaning here. cs)2 Technical Basics for Migrating Data to SAP Data migration is sometimes also referred to as data transfer Legacy system ‘The application system that contains the data to be transferred before the migration is referred to as the legacy system (or source system). Legacy data The data that is to be migrated from a legacy system to the SAP system is referred to as legacy data (or source data). Data object, business data object, business object ‘A data migration is usually based on data objects. A data object is a business data unit such as a customer master, material master, a Financials (F) document, and so on. Such objects are sometimes called business data objects or simply business objects. Data migration object, object When data objects are mentioned in the context of data migration, the terms data migration object or simply object refer to a data object with additional attributes that are relevant for the data migration, for example, the structure of the data object in the legacy system and the SAP system, along with the mapping that connects the two structures. File, text file, table-like file, sequential file All of the data migration techniques described in this book assume that the legacy data is available in one or more files. These files are usually text files, that is, files that are divided into several lines. The structure of these lines is differentiated as follows: If all the lines in a file have the same structure, that file is called a table-like file. In this case, the sequence of the lines in the file is usually not important for data migration. If all the lines in the file don't have the same structure (e.g. header and item records), the file is called a sequential file (see Chapter 6, Section 6.2.9). Frontend, SAP NetWeaver Application Server In the SAP system, files can be saved in one of two places: either on a frontend, that is, the end user's workstation, or on an SAP NetWeaver ‘Application Server, which is the computer that runs the application logic of the SAP system (or a storage medium accessible to the SAP NetWeaver Application Server)‘The Data Migration Process from a Technical Perspective | 2.2 2.2 The Data Migration Process from a Technical Perspective Regardless of which migration procedure you select, every data migra- tion project involves certain basic technical steps. The five steps dis- cussed in the following subsections are characteristic of almost every data migration procedure. 2.2.4 Exporting the Data If you don't use an ETL tool (see Chapter 8) for the data migration pro- cess, you must first export the legacy data from the legacy system. This step is also referred to as extracting or unloading the legacy data. The data migration procedures introduced in this book don't provide any support for exporting the legacy data from legacy systems. You'll need to determine whether your legacy system offers functions for this purpose. If not, you'll need to write suitable programs for data extraction in the legacy system. In the process of exporting data, you must define how you want to store the legacy data. In particular, you must decide whether you want to group all the legacy data together in one file or divide it into several smaller files. You'll also need to define whether you want to write the legacy data to table-like files or to sequential files. 2.2.2 Reading the Data Technically speaking, the legacy data exported from a legacy system can be saved in different files (see Chapter 6, Section 6.2.9). It may therefore make sense to transform the data to a technically standardized format initially. However, most of the data migration procedures don’t support this option. Instead, it's assumed that the legacy data will be provided in a predefined format. Of all the data migration procedures introduced in this book, only the Legacy System Migration Workbench (LSMW) offers this option. In this case, the files, which can exist in different formats, are merged into a sin- gle sequential file. (For more information, see Chapter 6, Section 6.2.9). 45 Legacy system responsible for data extraction Transforming data to astandardized format2 | Technical Basics for Migrating Data to SAP Convert the legacy data to SAP format Po] Value conversion Data migration using SAP Data Services goes even one step further. In this case, legacy data can be presented in any format, for example, as database tables, flat files, or Microsoft Excel files. In addition, it's possi- ble to use and combine all different formats within one business object (see Chapter 8, Section 8.3.2). 2.2.3 Converting the Data Application systems can model business data in many ways. You can't assume that the data you export from a legacy system can be easily imported into an SAP system without additional processing. Conse- quently, you usually have to convert the exported data to the appropri- ate format (ear meee The term convert is used synonymously with transform. The terms data con- version and data transformation are also used in this context, as well as map- ing, field mapping, and transformation, The data conversion can be as complex as necessary. The effort required depends on how different the source and target formats are from one another. To make the work less cumbersome, however, you can define typical conversion tasks that must be performed repeatedly: > Converting values Value conversion involves translating a known set of possible field values to a different set of values. This can apply to the country codes, for example, if the legacy data stores this information in a one-place field ("D" for Germany, “U" for the United States, "I" for Italy, etc.), while the SAP system uses ISO codes that can be up to three places long ("DE" for Germany, “US" for the United States, “IT* for Italy, etc,). In this ease, the following conversion must be defined: DDE Usus Ioit This process is also referred to as translation.‘The Data Migration Process from a Technical Perspective | 2.2 > Converting field attributes The conversion of field attributes involves changing the representa- tion of certain field contents. Let's assume, for example, that your leg- acy system saves date values in the format DDMMYY (such as 311215), while the SAP system expects these values in the format YYYYMMDD (such as 20151231). You must convert these values accordingly. You can do so with custom programming or by using a tool that supports such standard cases at the touch of a button. > Defining default values You may also need to define default values for certain field values. Always keep in mind that the data objects in the SAP system are usually quite extensive. In most cases, your legacy system will contain only a fraction of the fields that are available in the SAP system for a given data object. Frequently, you'll encounter situations in which the SAP system expects a value for a field, but your legacy system doesn't have an equivalent for that field; for example, the company code used in the SAP system is a variable that is unknown in many legacy systems. There are two basic ways of dealing with such situations: If the desired value can be derived from other available data, then you can fall back on a simple conversion of values (translation). If the desired value is always constant (or at least for long periods), you can set it to a constant. The technique of using fixed values, which provides a greater degree of flexibility than working with constants, is introduced in Chapter 6, together with the LSMW (see ‘Section 6.2.8). In the extraction, transformation, and loading (ETL) tool, SAP Data Services, this kind of defaulting can be achieved by means of global variables (see Chapter 8, Section 8.3.5). » Converting structures Insome cases, you not only must convert field contents and field attri- butes on the way from the legacy system to the SAP system, but you must also change the overall structure of the data object. For example, let's assume that a legacy system can save a maximum of three contact persons for a customer. Let's also assume that these (maximum) three contact persons are saved in the header record of the customer master record. You can define any number of contact 47 Converting field attributes Default field values Converting structures2 | Technical Basics for Migrating Data to SAP Direct writing to the database persons in the SAP system. A separate table record is created for each contact person. Therefore, in this case, you must convert the structure as shown in Figure 2.1 Legacy system Conversion of structures Figure 2.1 Converting Structures Example 2.2.4 Importing the Data All the previous steps serve to successively convert the legacy data into a format that the SAP system can process. The next logical step is to transfer this converted legacy data to the database of the SAP system. In addition to importing data, the term loading data is also used, as well as uploading to SAP. There are generally two options for importing data: » Write directly to the database tables If you fully understand how the structure of database tables works in the SAP system, you can use an ABAP program to write the legacy data directly to the database tables, at least theoretically. When it comes to throughput~the number of data records processed in any given time unit—this method is unbeatable. However, we don't recommend using this procedure because of the incalculable risk involved; namely, if this technique is used, the database of the SAP system could be filled with data that is inconsistent according to the rules of the SAP‘The Data Migration Process from a Technical Perspective application. Consequently, you might not be able to process it further, or even display it, in the SAP system » Use interfaces All the procedures introduced here employ the second option. They are based exclusively on the interfaces provided in the SAP system. In the following sections, these interfaces are called standard interfaces The following standard interfaces are used in this book: > Batch input Batch input refers to both a standard interface and a procedure for data migration. This mature, proven technology “feeds" dialog trans- actions with the provided data (usually in the background). This ensures that all input checks are run and that all data imported with batch input is correct and consistent in the SAP system. Of course, this, certainty has its price—the data checks reduce throughput. > Direct input Because throughput from batch input isn't always sufficient, direct input programs have been written for some data objects. In a sense, direct input involves the controlled, direct writing to the database of the SAP system. > Business Application Programming Interface (BAPI) BAPIs were originally developed to open the SAP system for external access. Data objects usually have read and write BAPIS. The latter can also be used to transfer data to the database of the SAP system during a data migration. > Intermediate document (IDoc) Docs come from the electronic data interchange (EDI) environment. The challenge here is to transfer documents (e.g., purchase orders) electronically from one application system to another, possibly very remote, system. To do so, the structures of these documents first had to be defined for business purposes, This resulted in the development of IDocs, or more precisely, IDoc types. Secondly, a technique for pro- cessing these documents in the SAP system had to be developed, namely, inbound processing. As you'll see in Chapter 7, you can also use this technique for data migration. 49 Using standard interfaces 2.22 Technical Basics for Migrating Data to SAP Connection between BAPIs and |Docs No blanket solution An important connection exists between BAPIs and IDocs. At the touch ofa button, you can generate an [Doc type from a BAPI in the SAP system. SAP already supplies the generated IDoc types for some BAPIs. In general, inbound processing of IDocs involves the data that is received in an [Doc is passed on to the corresponding BAPI, which updates the data in the SAP system. This process is described in more detail in Chapter 5 through Chapter 8 2.2.5 Verifying the Data Of course, after the legacy data has been imported into the SAP system, you want to ensure that the process is complete and accurate. Unfortu- nately, there is no blanket solution for measuring the success of a data migration. Ultimately, you'll have to rely on random samples and plausibility checks, such as comparing key figures (e.g., balances) or comparing the number of records between the legacy system and the SAP system. 2.3 Overview of Technical Procedures for Data Migration This chapter concludes with 2 summary of the major data migration techniques introduced in this book, including batch input, the Legacy System Migration Workbench, and SAP Data Services. 2.3.1 Batch Input As mentioned in Section 2.2.4, batch input is both a type of standard interface and a procedure for data migration. Batch input can be used for data migration in two ways: » Standard batch input programs The SAP system contains various batch input programs that transform prepared legacy data into a format that dialog transactions can pro- cess. These programs are called standard batch input programs. 50Overview of Technical Procedures for Data Migration | 2.3 » Batch input recording In addition to the standard programs, the SAP system enables you to record the process flow of a dialog transaction and generate an ABAP program from this recording at the touch of a button. While these generated programs theoretically work just like standard batch input programs, they lack the flexibility to react to changing screen sequences. The clear benefit of a batch input recording is that you deal only with the input fields of a dialog transaction that are relevant for ‘your specific case. You can ignore all other input fields. 2.3.2 Legacy System Migration Workbench ‘The Legacy System Migration Workbench (SMW) is an SAP NetWeaver-based tool for the one-time or periodic transfer of data from legacy systems to SAP systems. It provides easy-to-use functions to con- vert legacy data and import it into the SAP system using SAP standard interfaces. The LSMW is based on the following principles: » Business data objects are migrated, not individual tables or field con- tents. » The most frequent conversion tasks (see Section 2.2.3) are predefined and available at the touch of a button. Conversions can be added via the suitable ABAP statements. » No ready-made conversion programs are provided. Instead, the con- version programs are generated from the defined conversion rules > Quality and consistency of the data imported into the SAP system are more important than speed and throughput. Therefore, only the SAP standard interfaces are used. » Conversion rules that have been defined once can be reused. These techniques are introduced in exact detail in the following chap- ters. 2.3.3 SAP Data Services SAP Data Services is an ETL tool and hence capable of extracting, trans- forming, and loading data. Therefore, it can be used for data migration. 51 LSMW principles