In Episode 61 of Razorleaf’s Stay Sharp podcast, Critical Considerations in PLM Data Migration, co-hosts Jonathan Scott and Jen Ferello welcome back Michael Welti, Managing Director of Razorleaf UK, to delve further into the topic of data migration. The trio explored the basics of data migration in the PLM space in a previous podcast episode, The Essentials of PLM Migration Explained, and in this discussion, they dig deeper into the complexities of handling the data—which is relevant whether you’re migrating data to PLM or any other enterprise system.
Mapping Between Systems is Critical
Jonathan sets the context for the conversation, explaining that when thinking about the standard process for data migration—extract, transform, load or ETL—there’s a lot that goes into the “transform” stage. Specifically, how the data needs to be changed from its state and behavior in the source system to the desired state and behavior in the target system. Michael notes that the point is defining the mapping between the same data in those two systems.
Michael goes on to explain that attributes are information about a file and/or its metadata. “Who created it? When was it created? Those are attribute information. And then you’ve got the relationships between them. For instance, between an assembly and a part, you’d have a relationship to say this part is inside of this assembly. In PLM, it’s all about objects and links and how you move between systems.”
Jen points out that mapping may seem easy when you’re looking at data moved from one system to another—one-to-one mapping. But data migration is rarely that simple. To begin with, she points out, the same part type, object link, etc., may have very different representations in different systems. In addition, you may also be migrating data from multiple different sources with different representations into a single system. The bottom line, Michael says, “You need to make sure you get all the information across in a way that once it hits the target system, you can use it, the target system works as its meant to work, and you’ve got all the requirements being met.” Adding to the complexity is the fact that this migration needs to occur at speed, at scale, and in an automated fashion. There’s no time to do it manually.
Adding the “Analyze” Step
As Michael explained in the trio’s first podcast discussion, ETL isn’t enough to guarantee successful data migration. At a minimum, you should add a stage after extraction to analyze the data before transforming it. “That analysis bit is really key,” he says, “because you’ve got to know exactly what you have in your source system to then help you drive and work out what your mapping is going to be, which then helps drive your transformations.” The analysis helps with more than just the technical details of how the data needs to meet the requirements of the target system. Michael points out that some mappings, “have a bit more choice involved. It’s more of a business decision about where should this go? Should we keep it? Should we not keep it?” Those kinds of questions also come up in the analysis and mapping processes.
Beyond Mapping to Use
Jonathan emphasizes that the analysis phase—and the entire data migration process—should also consider the people factor. “You can map data all day and make sure the data that was in your source ends up in your target,” he says. “But you can also do yourself a disservice if you didn’t think about how it needs to be used in that target.” Michael concurs, saying, “That whole business transformation bit needs to be taken care of as well as taking care of the data”—meaning you need to consider the transformation of business processes or how people are going to use the data in the new system.
How users need to use data is especially relevant when considering how to migrate historical or legacy data and represent it in a new system. “It comes down to more of a business decision about what they want to bring across,” Michael says. As Jonathan puts it, “Some history you need to be able to modify, change, and carry forward, and other history, you don’t.”
Learn More About Transforming Your Data While Migrating It
The full podcast contains more discussion and details on a variety of topics, including the sticky situation of historical user information as it relates to parts or assemblies, the challenges associated with the idea of “locations” for data being migrated, why you need to do your data migration as quickly as possible and what that means for the planning stage, and more.
Check out the full conversation in Stay Sharp Episode 61: Critical Considerations in PLM Data Migration, as well as the trio’s initial conversation in Stay Sharp Episode 59: The Essentials of PLM Migration Explained. And be sure to join us each week for a new podcast.
Follow the Razorleaf Podcast, Stay Sharp in Digital Engineering on:
