Often companies underestimate the work involved with converting legacy system data for a new SAP implementation or upgrade. Because the teams involved tend to focus their skills in certain areas, they tend to use the same steps for each project.

What if the teams were to change their focus so that they continued to build on past experience to improve processes, plans, toolsets, and skills? Such a change in focus adds value to the ongoing conversion tasks and it makes it easier for the project teams to work together. More importantly, it provides the IT team more time to learn the new technologies involved.

I provide details about what you should consider when you plan a legacy-to-SAP conversion, using the materials management module as an example. In addition, I discuss items that may affect SAP system upgrades. To get the most out of this article, you should have a basic understanding of ABAP and BAPIs (for calling ABAP functionality). You should also have some general knowledge about networking and Windows file types, as well as databases and business systems in general.

Know Which Project Areas Can Cause Delays

It’s important not to oversimplify the project, opportunities, or challenges before you. Moving forward without a well-defined conversion project plan is a mistake. Unless you are building a very simple SAP system with limited unique changes, you should know the required functionalities, specifics of those functionalities, options end users need, and areas in the SAP environment that affect other functions and areas. For example, if you define that all documents stored in the MARA table are Adobe PDFs and automate the type to always be PDF, what happens when someone needs to store a parts list in Microsoft Excel format? By anticipating what the users need, you limit code rework and confusion.

Here is a list of areas that derail your SAP implementation project:

• Lack of understanding of what is involved in a conversion can cause issues. For example, a new client SAP system requires understanding of code maintenance and transports in the SAP environment as well as an understanding of Basis, configuration, and communication tools such as Application Link Enabling (ALE).
  
  Also, simply moving all the data from one system to another doesn’t constitute a conversion. Successful conversions should not only import data correctly, but include some form of data cleansing, indexing, and validation when possible.
  
  Your conversion is not a success if once-good legacy data is now incorrect or — worse — lost. You have to know what data you need to store together, throw away, or file differently. You need to know what scraps of data you should make meaningful and the data for which you need extra (new) copies.
  
  
• Remember that you may be going from an unstructured legacy format to a structured SAP architecture that could require further analysis. Don’t rush to judgment concerning the difficulty of specific conversions steps. Brainstorm with your conversion team, think it through, and find the route that allows you to do what is right, not just what is easiest right now.
  
  
• Recognize that conversion-related changes are likely to affect your company’s communications infrastructure, back-end hosts, support structures, and capacity. The tools your company uses to manage the new system are likely to change as you move forward. Promise small and deliver large. This is a huge project effort and everyone will want everything at once. Moving dirty data to your SAP system may create more cleanup work later, which can affect the system’s effectiveness, complexity, quality, and usefulness.
  
  
• SAP knowledge in itself isn’t always the best solution for all your conversion needs. Sometimes, the best tool for the job isn’t the latest SAP or Windows development toolset; it’s just a simple command file. For example, instead of spending time writing a Visual Basic .NET, or Java application to extract a simple directory listing for conversion (as well as the effort required to deploy it), consider something much simpler: a Microsoft NT command file.
  
  
• Make a point to learn other skills and then use the best tool for the job. Even if you don’t use those skills, you may find different ways to apply your SAP knowledge.
  
  
• Support functions that are already in place for other applications may not fit the new SAP model. Help your organization to recognize at an early stage the technical, business, and support shifts that you need to make. Include the development staff during planning, development, and testing. Provide continued briefs for the business staff during the project build and test to help them to see what they need for long-term support and process changes.
  
  
• Consider what effect system updates — such as SAP hot patches, legal change updates, functional updates, Basis updates, configuration updates, and cross-platform testing — will have on users and systems.
  
  
• The cost of hardware, software, router upgrades, network cards, toolsets, training, network support, and contractors can push the project’s cost well over budget. Early in the project, discuss your plan for items such extra storage media, application support or maintenance costs, document or media servers, and extra CPUs.

Best Practices for Deployment Success

Now that I’ve defined the areas of concern around deployment of a successful SAP system, here are some tips to ensure the success of your implementation.

Team Building Best Practices

Do what you can to make the SAP project build a team solution. For instance, the business may agree to a certain design or conversion path, but it may not be the end users’ preference.

Also, include your vendor and your lowest-level employees as part of the planning team. Recognize that the way something was done in the past may no longer pass muster and that someone with absolutely no SAP background may provide you an idea that will make you and your team look great. You should also include legacy knowledge experts. You can learn a lot from them. You might even want to consider cross-training them as you go through the project.

As a team, define what you consider project success. Just meeting a scheduled date with a semi-working product is not a success for most high-quality organizations. In addition, ensure that everyone on the team knows who is responsible for what and make open communication an expectation. For example, providing details about the environments being used, availability, new transactions, configuration status, and process status is much more important to your development staff than spending hours poring over PowerPoint presentations that don’t provide the details the development staff requires.

Data Management Best Practices

As important as it is to build your team, you also want to make sure that your data is prepared for the conversion. Data items to consider include:

• Data type
  
  
• Data size
  
  
• Data availability
  
  
• Data source
  
  
• Data formatting
  
  
• Data validation
  
  
• Data transfer
  
  
• Data tools

Data type: Determine the format of the incoming data (e.g., ASCII, Extended ASCII, EBCDIC, or Unicode) and how the format affects your conversion. Find out if utilities are available to convert the data for you or if you need to build conversion utilities. If your storage system or OS doesn’t support extended ASCII, decide how to handle the special extended ASCII characters at conversion.

If your data has not been managed correctly, your end users are likely to see unprintable or non-displayable characters on their screens. Poorly managed data also adds the potential to corrupt data parsing if that is required in your application. A simple solution is to add an ABAP routine for your conversion developers that converts data to a readable format.

For example, you may only consider ASCII HEX codes 20 (space) through 7E (tilde) as valid displayable characters. In your conversion, you may want to globally replace all other character values outside this range with HEX code 20 (space) or even make a larger conversion such as replacing HEX code 96 with an ASCII dash (HEX code 2D). This functionality may be worthy of reuse at many projects as you build your toolkit. However, make sure that you do not convert appropriate ASCII formatting codes (such as in Excel, Word, graphics, or other documents).

Data-sizing issues: Plan how you will you handle data that is shorter (or worse, longer) than the SAP fields being filled. Will zero or space padding be required? For example, the SAP MARA tables expect the item number to be 18 characters long, zero padded. If you use a character number smaller than 18 characters, you can simply pad the number with zeros. However, if you use 19 characters or more, you need to come up with a plan.

Also, interfaces with many trading partners can have a huge effect on your project. Ensure that these numbers are either tracked correctly or converted to an internal SAP number using a cross-reference table.

Data availability: You need to know what is required to access the data, when is it available, what security is required, and what system type you need to emulate. Assess the availability of legacy personnel to assist you in extraction tasks. Does the data being converted included data that should not be extracted, as in the case of a shared database used for multiple systems? If so, how do you extract just the data that should be converted?

Is there static data (for example, previous year data) that you can export early and possibly import early to shorten the export process? What is the overall conversion time frame? Start by building a data extraction plan that includes these parameters.

Your legacy experts can probably provide you the data you need in the format you need it in, given appropriate time and expectations. For example, in the case of a database system housing data for multiple applications, the legacy developers know the best way to extract just the data that is being converted and can probably provide cleanup for you after conversion.

Similarly, the combination of legacy developers, system administrators, and end user business analysts can probably help you determine what data is static and can be exported early on saving time at conversion.

Data source: Determine the data source type. For example, will you be using SQL to extract data from Oracle, IBM DB2, or other relational tables? Be aware of data systems such as mainframe VTAM or IMS systems that require legacy developer assistance for extract. These could require specific expertise not widely available by your staff or take longer than other conversion areas.

Find out if any documentation is available about the data structure of the data. If it is not available, see if you can gain access to the data to begin analysis of the structure.

Determine how metadata is defined. Is it within the record or outside the system? How can you best maintain the relationship between the two? If the metadata is outside, you may want to consider linking the tables together to simplify the SAP input file.

If you have hard data, such as paper or microfiche, you should look at whether it is better to digitize this data or manage it separately.

Data formatting: Find out whether the output format imported into the SAP system will be XML, flat file, comma-separated value (CSV) files, graphics files, documents, PDF files, or something else. Then determine which data formats the SAP instance is prepared to manage and which data formats you need to test or modify to support a proprietary or unplanned format. If you can standardize the format somewhat, it may simplify your development of conversion programs.

Learn where you can find out what the proprietary formats should look like and how to manage them within the SAP system. What about system unique files, such as legacy mainframe data? You should know who will perform the extract to export it as single records.

Data validation: Part of your plan needs to be a defined validation of conversion data. Data validation should preferably occur once, at data entry — not at application runtime. Although you can make form corrections to convert data at display, it means your system is constantly performing operations that should have been done once. The impact is minimal, but that kind of thinking tends to breed similar slippages in code quality throughout and will affect your system at some point.

Here are some important data validation tips:

• Verify that protected data remains protected as soon as the import is complete. If possible, make the data unavailable to other users while import is running. Verify that your test systems have the same SAP and BAPI versions as the production systems.
  
  
• After you import, verify that each record or file imported is correctly accessible within the system. Limit the need for users to download data from the SAP system to their workstations.
  
  
• Always verify parent record existence prior to assuming valid import
  
  
• For documents and graphics files, verify that the document management system and document viewer can read and display the files correctly. If you have files that don’t match the viewer configuration, consider other viewers that may work. For example, file viewers not only view text files, but also allow you to view many other file types such as logs, trace files, and CSV files.

For a simple but effective data validation technique, refer to the sidebar “Track Imports for Quality and Validation.” This sidebar is available in the Downloads section at the end of the article.

Data cleansing: Manage downtime by converting static (previous year or other unchanging) data early. This also provides the opportunity to better validate your conversion. Also, rename files before conversion if their length or file names conflict with your import requirements.

If you need to manually cleanse the data, find out how quickly you can start this process and determine who is available to assist in it. Have manual cleanup completed, or at least started, early in the project.

Only convert what you need to convert. Make sure you aren’t extracting data from shared systems that doesn’t apply to your project.

Data transfer: Develop a plan for transferring data from the source extract to each of the SAP systems (development, test, and production). Know what archival hardware (cartridge, track tape, CD, DVD), software, or direct transfer methods (FTP or sFTP) are available. Be aware of limitations that may exist on the use of the equipment as far as time, size, and other areas.

If you have secure data, make sure you keep it encrypted and secure when it is outside the host system. For example, banks often use hand-delivery of some encrypted items — such as portions of encryption keys — to business partners to limit data access.

Determine the best time to extract the data and to be sure that you extract all of it. You should perform a pre- and post-check on the numbers of items in the extract to verify your export.

Understand any unique differences that may exist between the source and target systems. For example, some systems allow a file to end with a period, whereas others do not. Windows allows for long file names while some file systems limit the number of characters in a file name. UNIX systems use a different delimiter (/) than Windows NT-based systems (). How does this affect your backup and restore utilities? Using a character conversion parser in your export may resolve this issue for you.

Most organizations have a specific extract or load order to provide for data and linking validation. Are they different?

Data tools: See if tools are available (even desktop tools) to improve the quality or speed of the data conversion. For example, sometimes an Excel macro can resolve formatting issues. You also may have system-specific export tools already available on the legacy system. Choose tools based on what they add back — don’t just choose newer for the sake of newer.

System Upgrade Best Practices

Converting from a legacy system to an SAP system may also require upgrades and changes to your hardware and configurations of your systems that remain in place. These updates can include:

• CPU upgrades
  
  
• Memory increases
  
  
• Operating system upgrades
  
  
• Disk space increases
  
  
• New peripherals
  
  
• System balancing
  
  
• Batch processes

Plan your time accordingly for these changes, such as the time needed to update or temporarily disable existing SAP systems to complete this conversion. You also may need to add new interfaces and update or delete existing interfaces. This is also a good time to figure out if you can improve or automate your interfaces.

Also, know what security issues are likely to arise, such as data safety during transfer or at rest on your SAP system. You may need to change your configuration to protect this data as well as to make it updatable and usable by those who need to access it. However, system changes to applications could become a security risk, so make sure you involve the appropriate people. Security is a huge issue and more complicated these days. Make sure your timeline allows for enough time for this area of concern.

Consider how you want to handle code from existing SAP systems. Code reuse and standardized functionality are fine, but don’t follow them blindly. Make certain that they are still viable for your project, including validating that the code is still applicable and that newer or better code isn’t available. Ensure that any known code issues are recognized and managed. Use your test logs to verify data loads with production data and modify code or data as appropriate. This includes updating obsolete BAPIs.

In addition, recognize that other projects may need to interface with this code or new requirements may come about that require change. For example, if you already have SAP modules in production and you are adding a new module and new functionality to an existing module, make sure that your code change doesn’t break an existing system.

Similarly, when using custom off-the-shelf (COTS) packages, you may find issues that require changes or updates to your configuration. Know what configuration options affect the application in more than one place and what changes require a major process rebuild.

The bottom line is to be careful about making assumptions about the ease of data extract. Legacy and proprietary systems may not have the simple extract tools you may expect. In a recent effort, my team and I found that no system documentation, import utilities, or extraction expertise were available for a document management system. It took several weeks to gain access to the system and analyze the semi-disguised 700-plus tables to determine the data format, data linking to system files, metadata information, and formats to make the data usable.

Apply the Best Practices to Your Project

Now that I’ve discussed important best practices for your project, I will walk through how you can apply these best practices during the planning and testing stages. I will also provide some tips to ensure that knowledge transfer during these phases runs smoothly.

Planning

It is vital that a detailed project plan be in place early. The project staff must agree to the plan, including reasonable hours to facilitate ongoing system support and other projects. I don’t mean a 50-page Microsoft PowerPoint document with pie charts and pretty fonts, but you should have a detailed list of items you want to accomplish and the team members assigned to those tasks. You should plan for worst-case scenarios, including gaining system access and conversion time frames.

Make your contacts early — even if you don’t need them until later — and note their availability schedules. Don’t wait until late in the project to expect help from legacy or other company employees just because your project is deemed important.

Also, consider the time it takes to gain file system and application access. View the project in the long term, and establish a step-by-step plan. Build a conceptual framework for the future needs and then expand to those functions as time allows and phases are completed.

Look for problems before they occur so you don’t create a time delay. If you find functional or technical issues during development, note them for testing. Prepare early for long-term management, including operating system updates, SAP updates, BAPI updates, and configuration changes. Deciding how to manage these changes needs to be thought through, developed, and thoroughly tested. Review your capacity planning and customer availability model with the new changes to your systems.

Finally, consider what can be put in place to support the application changes in the future. If you are exploring new file types, see if you can preconfigure them. In addition, be aware of the volume of documents the project will create in case you need to go to a new document management server because of increased volume.

Testing

In this phase it is important to create many types of good and bad test records. Automate data builds where possible to speed testing cycles by using macros, scripts, and smart tools. Also, reuse code when appropriate.

Build cases that you know should fail and make sure they do. For example, missing files, empty files, invalid data, child data without parent data, invalid numeric fields, invalid values, and long field length are all great negative test cases that you should test.

Include record counters and error tracking in your load code to assist in data validation. For example, if you are loading extended ASCII characters into a system that only correctly displays standard ASCII characters, include and verify the character conversion as you import.

Test not only entering form data with a keyboard but using copy and paste to make sure formatting issues are managed. If volume and stress testing tools are available, use these to test also and if possible set up a system equivalency test to estimate your conversion time. Make note of your loading throughput and timing.

Here are some proven testing techniques that I have used:

• Run tests on your conversion code using production data
  
  
• Verify the view and readability of several imports of each file type imported as well as correct linking to SAP systems data (e.g., MARA) and parent records
  
  
• Review loaded data to determine why production data loads failed before you convert. Determine whether the data is valid or not, and if so how it can be updated for a successful load. For example, when BAPIs change, it often affects your code.
  
  
• Plan for and check the good and bad load logs

You can save some time during your project if you follow these system performance tips for testing:

• Remember that writing is more expensive than reading so you want to test with a similar number of system writes if possible
  
  
• When you test, try to select subsets of non-sequential records to limit cache use
  
  
• Consider system performance aspects such as data buffering when accessing tables:
  • Consider a 10-25% buffer for volume and stress testing
    
    
  • If batch or background services or processes are running during import, deployment, or application use, make sure the same services or processes are running during your import test

Documentation and Knowledge Transfer

Build an excellent knowledge transfer and support plan. For your technical knowledge transfer sessions, include the following:

• Networking changes
  
  
• Protocols
  
  
• Standards
  
  
• Security
  
  
• Capacity and volume
  
  
• New hardware and cabling requirements
  
  
• New software and connectivity requirements

Also, include business knowledge transfer sessions, including new breakdowns in personnel and new and newly revised procedures. I’ve listed some specific items to consider in the “Knowledge Transfer Suggestions” document, available at the end of the article.

I think the hardest part for most developers is to hand off information, especially well-documented information. Unfortunately, this plays a huge part of the success of an implementation. Cross-training and knowledge transfer should be a consideration from the start and should be built into the project plan from the beginning. It should include an end-to-end understanding of all aspects of the project.

Your SAP implementation can go much better by encouraging recommendations for sharing the following:

• Code improvement suggestions (e.g., how can this be made faster and more accurate?)
  
  
• Code memory management suggestions (e.g., am I making code changes that will overuse memory?)
  
  
• Data cleansing suggestions (e.g., what is the best way to remove these invalid characters?)
  
  
• Development and data standards (e.g., how do we build a standard for our new data elements?). On an SAP project I worked on, there were actually five names for the same data element in three different formats.
  
  
• Keep your development and test environments separate. Do all of your configuration and build in development before moving to the test environment.

Your Next Conversion

After reading this article, you should have a long list of items to consider for your next legacy to SAP implementation of conversion effort as well as, hopefully, a kick start to help you define even more ways to improve your systems. As you continue in your SAP implementation or even updates, continue to expand your plan and use this information to build a working toolkit to improve the quality and timeliness of your projects.

Bottom line — conversion should only occur once. If your project starts with teamwork input, good communication, thorough analysis, and a good plan, your SAP implementations will be lauded, less problematic, and better built. To assist you, I’ve included a few more files at the end of the article:

• Sample File Types: Word document to assist you with obtaining a list of the file types to be converted
  
  
• Sample System Analysis: Word document to assist you with obtaining a list of the data types, locations, and contacts
  
  
• Sample System Map: TIF image to show you what a sample system might look like

Tom Sullivan

Tom Sullivan has designed, developed, and supported IT systems for private industry and public service agencies for more than 27 years. In addition to his recent involvement with conversion of legacy to SAP projects, he has worked in nearly every area of IT systems with recent stints as a technical project lead for ATM Systems for SunTrust Bank and is currently working with Sun Identity Management software. The views expressed herein are those of the author and do not necessarily represent the views of his employer.

You may contact the author at psalmist7@comcast.net.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.