In Episode 67 of Razorleaf’s Stay Sharp podcast, Pitfalls and Landmines in Migration, co-hosts Jonathan Scott and Jen Ferello are joined for a third time by Managing Director of Razorleaf UK and migration expert Michael Welti. The trio’s previous discussions—Stay Sharp Episode 59: The Essentials of PLM Data Migration Explained and Stay Sharp Episode 61: Critical Considerations in PLM Data Migration—covered the process of data migration and some of its complexities. This conversation, about what not to do in a data migration, is a logical offshoot of those, specifically focusing on how to avoid the landmines in the process.
Just the Right Amount of Data
Jonathan identifies the first pitfall, which concerns what data to migrate, saying, “Don’t bring stuff you don’t need, and make sure you get everything you do need.” Michael agrees, adding that doing so relies heavily on understanding both your source system and your target system, including if your new or target system will be able to handle and represent all of the data you want to move. The gotcha Jonathan has encountered involves customers choosing a target system that doesn’t have a certain capability they had for data in the source system. Since it wasn’t a capability the customer was using anymore, they thought, “I don’t need it in my new system, it’s not a big deal,” Jonathan explains. “But what they missed was, well, I did have data that was related to that, which I needed to bring over and I didn’t want to lose.”
Migrating data between systems isn’t just transforming and moving it. Michael says, “You’re migrating your processes and how you work. Making sure you’ve got everything you need in place to use it moving forward.” What this often requires—another pitfall that often trips people up—is taking the time to understand your data. You shouldn’t be cavalier about your data and decide you need it all, unless you take the time to consider the implications. “Do you really want the workflows or history or some of the details that you’ve not used for 20 years? Or stuff that has migrated from a previous migration?” Michael asks. “Do you really need it? Is it important?”
Understand Your Data’s Constraints
Another potential landmine is considering your data’s constraints. As Michael puts it, “You’ve got to really understand what does all that data contain—all that historical information, all those different ways of representing information.” That’s particularly challenging when systems have been in place for a long time and users have found lots of innovative and non-standard ways to use them, which isn’t a problem until you need to migrate the non-standard data. A single data set needs one defined set of migration rules, which may mean taking into account current and legacy data representations.
That’s where the point Michael made in previous podcasts really comes into play: you shouldn’t only extract, transform, load (ETL), you should extract, stage, analyze, transform, and load your data. And you need to do it all while also keeping in mind the constraints of the target system you’re moving the data to, especially how your target system handles data context. “In PLM systems you talk about objects and links. Things interrelate so an assembly links to a sub-assembly, which links to a part,” Michael says. “You’re migrating things in the context of other things. So as you migrate, you’ve got to make sure that context and what it infers is also carried across.”
Rehearsals are Key
The trio agree that it’s important to discover any problems as early as possible, because you want to figure out if you’ve got a problem with your data during the analysis stage or in a test environment, rather than in production after you’ve migrated 90% of it. “Don’t assume you’ve got it right,” Jonathan says. “Make sure you’ve rehearsed sufficiently.” Which means, practice all of the steps in a practice environment, but also try to use the data you’ve migrated. Michael adds, “That’s a step that people sometimes forget. We’ve migrated, it looks good. Have you tried to revise it and do a bit of design work? Because that’s usually the key test.”
Learn More About What to Avoid in Data Migration
The full podcast contains more discussion and details on a variety of topics, including considerations for maintaining the security of your data during a migration, what to do when you find a problem with your migration weeks or even months later, why you need to be honest about the skeletons in your system closet, why Jonathan calls data migration a Goldilocks topic, and more.
Check out the full conversation in Stay Sharp Episode 67: Pitfalls and Landmines in Migration, and join us each week for a new podcast.
Follow the Razorleaf Podcast, Stay Sharp in Digital Engineering on:
