By Matthew Costello
A business migrating data from a legacy software into any new system, including SAP, has hurdles to overcome, even once the high-level plan for the migration has been discussed and put in place. There is more to it than just moving files from one storage location to another. Ideally, the migrated files will be searchable, usable, and migrated in a way that best suits the business needs. In part one of this blog, we discussed considerations for coming up with a migration strategy, as well as how to relate the legacy system to the SAP system. Here, we will talk about some of the key details that can make or break the end to end migration processes such as data extraction, metadata mapping, and standardization. We will also touch on data cleansing and responsibilities.
Details about export and metadata processing of legacy documents are best left for after overall strategies decided. Information collected about the legacy system, the SAP system, and the metadata mapping will help facilitate how the data should be extracted and staged before migration. If the data is in a legacy vault, there are a variety of methods to get it back out in an organized and readable fashion. In most cases, there will need to be some method of data extraction weather through tools or manually. If the data is on a shared server, there is no need for extraction; but there is a downfall as the metadata is then stored only within the files themselves, adding the need to obtain the metadata. CIDEON’s Import-PDM Tool overcomes this hurdle by reading and gathering this information for you, making it a powerful asset in creating or enhancing metadata files. Take this opportunity to decide how and when to clean up and standardize metadata field information.
When working on data cleansing and standardization, there are usually similar issues from customer to customer. For example, a common occurrence from legacy systems is free entry fields that could have been automated or selected from a list. SAP will accept any and all values with minimal intervention, but that doesn’t necessarily mean that this is a good plan. Let’s take the example of where a user enters a name in a field. Making these fields set values vs free entry enhances searching, eliminating cases where the same user name shows up in different forms. Aside from the obvious existence of typos causing issues with uniformity, the other problem is searching in the field for free-form entries is incomplete. If I search for “Matthew Costello,” I will not see any values entered as “Matt Costello,” or “M. Costello”, or anything else outside of that criteria. If I search for “Matt” to broaden my search, I will get more hits, but still not the full set. To search for simply “M,” would return a potentially unmanageable amount of hits, and I would not be able to sift through the data promptly. So while a multitude of values can be passed into SAP from legacy, this should be taken into account during planning, so fields that are commonly referenced by users are standardized for better performance going forward.
Finally, we’re on to data mapping. Mapping is one of the simpler tasks to accomplish as we have already identified which values will be used to populate corresponding fields in SAP. SAP values may be slightly or drastically different from legacy values. If so, discuss where and how this connection is made. Can the tool used for migration handle “If/Then” logic in its setup to read a value, and return another for mapping to SAP? Pull from a bank of values and populate the proper value based on chosen criteria? Direct mapping is also possible, though this requires additional cleansing to standardized values.
Formulating a migration plan is a detailed task, but the cleanup of data can be just as intensive. Data cleansing is one of the most critical missions in a successful migration project. Regarding CAD migration, the data that must be correct is file references. If references are missing when the data loads to SAP, structures can be incomplete and unusable, forcing the users to have to perform additional cleansing activities. Another key piece is the mapped values in SAP. These must be easily searchable. All users should be able to find everything to work with and reference to complete tasks quickly. If you have followed the steps laid out so far, you don’t need to sweat because you have already prevented this sort of sticky situation.
Also, to avoid migrating poor quality data, it is imperative to perform multiple mock migrations to ensure the migrated data is complete. As an unwritten rule, I undertake no less than three full mock production loads into a test system, and if I can plan for more, I do. Mock loads do not mean partial data sets; this means that we are going to mimic loading to the production environment, and then analyze the results. Analyzing uncovers challenges and provides an opportunity to cleanse. If any part of the load is a partial set, it should not count as one of the three. By following this plan, you get a full picture of everything involved after each iteration. It affords the opportunity to gauge performance and plan migration windows. It also formulates error reports of files or data that failed to load, and give us a starting point for data cleansing. These mock loads also serve as the perfect base for user acceptance testing in a quality system. The loads are representative of exactly what the users will have in the system on the first day of after go-live so that they start work on their most important files, every time. These activities make finding potential issues quicker, as the data is not “test” or “staged” data. To the user, it is living and breathing. So, with the users being familiar with it, problems are immediately identified and solved.
Alongside the activities above, it is also necessary to define “who is responsible for what.” As with any other project, there should be clear-cut lines of responsibility established early in the planning process to set the understanding of who will perform which tasks. For example, data cleansing must fall on the business users that own the data. An outside consultant cannot know what is correct regarding data, and will only be able to offer insight and advice as to what different options exist. When the tasks are lined up and laid out in order, the responsible parties understand what they will be doing, and planning and execution are clear. Assignments also eliminate misunderstandings and anything that may “fall through the cracks” because no one knew that they were responsible.
Ultimately, data migration outcomes are critical to your business. Taking the time to pay a little extra attention to the data coming into your SAP system will go quite a long way regarding SAP efficiency and implementation duration, while helping your users get working at full capacity sooner. With minimum effort, you can create a lasting impact on the success of your project by using the processes and tips outlined here. Your data will be cleaner, your users will be happier, your processes efficient, and your business will save time and money.
Please leave a comment or contact us at email@example.com with specific questions or share your thoughts and ideas on data migration for success.