By Matt Costello
When a business moves into the SAP world, they are simultaneously moving away from a legacy system, whether digital or analog. In addition to moving daily activities and processes into their new and shiny SAP instance, they will also need to move the data. Data migration is usually a large part of a company’s shift into any new system and can quickly become the thing of nightmares if the process is not managed appropriately from the start.
My background and education are in Mechanical Engineering, so I am no stranger to engineering data and its structure. I’ve been with CIDEON America for just over 5 years, and during my time here, I’ve worked on a multitude of projects from configuring Document Management (DMS) in SAP to SolidWorks and multi-CAD Integrations and beyond; however, most of my time is dedicated to data migration. This has given me a deep insight into data migration strategy, touchpoints, challenges, and testing as well has allowed me to encounter a wide range of data situations involving legacy systems and setups. From those encounters, I have built a very unique skillset and knowledge base for blueprinting, planning, and executing CAD migrations. So to keep you dreaming peacefully, I’d like to share some experiences and key topics with you that have helped me with successful data migration projects.
Let’s start with CAD data migration as a specific subset. While CAD migrations into SAP have many similarities to “flat” file migrations, where there is no parent/child structure, there are also many differences, some of which drastically affect migration strategy. In addition to characteristic, file, and other metadata, CAD files must be imported into SAP with a document structure – document being the specific nomenclature of SAP. This can be a very difficult task without the right tools to analyze the structures and subsequently create them in SAP – fully linked and with complete data. It is easy to put data into a system. It is of much greater value to the business to migrate in a way that the resulting data is searchable, usable, follows corporate security and permission protocols, and supports the CAD and downstream users future processes.
When formulating a strategy for migrations, first you must consider both the current and future systems data setup, usage, and how data is consumed. How is it exported out of the legacy format, subsequent metadata files prepared, and data transformation and referencing completed? Once this information is laid out you can formulate a plan for migration, validation, and data cleansing. To gain this knowledge and lay out the process I recommend starting with a workshop. During the workshop key representatives should be prepared to answer questions about current and future state architecture of the data. A short list of examples may include:
1. Where the data is currently located: In a vault or legacy PDM/PLM? On a shared drive?
2. Is the metadata stored within the CAD files themselves or stored separately?
3. What are the data values and how much metadata actually exists?
4. Is all history to be migrated or is there a cutoff such as only the latest released?
5. What will the parent/child structures look like?
6. Is status network mapping going to take place? And so on…
It is also important to get an overview of how the users work from day to day including searching, key fields, and functionality. Once you have the legacy system and data overview, you can then apply it to the SAP system. As a side note, all of this will be closely tied to DMS and CAD integration setups, so it is my experience that the persons involved in migration should also be involved in the DMS and integration blueprinting to ensure that all of the key pieces line up and the users get what they need.
Now that you know what the data is, where it is, and where it needs to be we can generate the roadmap to get from where you are to where you want to be. Regardless of the method used to move the data, data mapping should be done in a way to both capture the setup in legacy and support future usage. For instance, some metadata is more appropriately used in SAP as material master (MM), or functional location information. This information can be migrated as separate objects and object linked to their corresponding document information records (DIR’s). Other data is used to describe a file and should be used as characteristic or configuration information to further support a DIR and its object links in SAP.
For now, we have a high level overview of the CAD migration steps and considerations that will form a solid base for a successful migration. In a future post, we’ll dive further into the data, and further details that can be covered during a migration including how each further supports and benefits migration to SAP. We’ll also post on metadata mapping and how it can be handled in a way that makes data searchable, standardized, and concise as well as cover “flat-file” migration topics as they differ from CAD. In the meantime, if you’d like to discuss your data migration questions and needs, feel free to reach out to email@example.com.