Migration from a legacy application to a new.

When you have taken all the trouble and effort to develop your own or customize a vendor PDM application, you will want to populate the databases with the data of your current Parts and Products. That is regardless of how simple or sophisticated your old, mostly called legacy, application and databases are. And you will also want to phase out the old applications to get rid of costs and needless use of resources. 

There are cases when it is possible to start fresh with a new Product Engineering Project but mostly this idea is ”sabotaged” by all the ”carry over Parts” that are used in the Products to be replaced by the new Products to be developed in your new Product Engineering Project. Normally you will perhaps have next to 50% carry-over-parts or more. 

Migration will use your resources and be costly, regardless. 

There are a few ways to do it:

  • The first alternative has just been touched upon: Do not migrate anything else that the existing Parts you will need in your new Product. Migration of Product Structures is not done at all. You create all Product Structures needed in the new PDM Application as the Product Project develops. This will have an impact on Engineering Changes affecting the new Parts and Products in the New PDM Application and the old Parts and Products in the old legacy PDM application and you will have to live with double documentation of Parts and Assemblies for a while. 
  • The next way is to migrate manually or with some minor programming assistance. Put the masses to work for a short period. This way is not recommended if you have complex Products with lots of Options and lots of Engineering Changes. 
  • Another way is to use the information you have in the MRP databases where you will not have to worry about very much history. Let history rest with the old application. What you may win with this approach is a correlation with what is actually being manufactured and you migrate nothing else. You will, of course, have to consider the ERNs you have released or to be released and which are not yet updated and effected in the MRP databases. This approach may create a few problems if you are manufacturing the same Products at several Plants around the world. 
  • The last method is to ensure that the databases in the new PDM Application can be translated to from the old. You will have to have some kind of relation between the old and new databases that can be used to write a set of migration programs. This method is based on the requirement that it shall be possible to migrate in a mechanized way! 

The last method is the only option if you have several Product Lines with complex Products with several Options manufactured at several Plants and where you have frequent Engineering Changes and need to keep track of the Change History. This method also implies that the migration will have to be considered when designing the new PDM Application and it’s Databases. This implies that it is important to have migration possibility and method in mind when you are considering whether to make or buy and when you are specifying you requirements on the new application!

The migration is very often not considered to be very important or critical at the beginning of the PDM Application Project. Everybody engaged in the project are very busy with learning and customizing the new marvelous application that will solve all the shortcomings of the old legacy PDM application. 

However, very often the migration from the old PDM application to the new, may cost as much as half the investment cost of the entire project! 

Here are a few things you will have to consider:

  • Correlate the data (information models) between the old and the new databases. Define translation rules. Some of these rules will probably have an impact on how the data bases in the new PDM Application will have to be structured. 
  • Track all misuses of the old PDM application that will jeopardize a mechanized migration. This may prove impossible but it is still necessary to make an attempt. 
  • When designing the new PDM application, think about how much new things the different user groups will have to learn and how much time will be needed for education, their time and project time. Develop User Manuals and Education Materiel including practical exercises. The bigger the difference is from the old way, the more education is needed. How big difference is actually motivated from a user’s viewpoint? 
  • Consider how much data you should migrate and define what should not be migrated and why. Also consider how people who might need the data not migrated, should have access to this without running the old PDM application for several years after the migration. 
  • Consider all the down-stream applications using PDM data and the interfaces to these. Should these interfaces be kept as is and just have one interface from the new PDM application to the legacy application. This implies that the legacy PDM application will have to operated (in the back-ground) for a considerable time after the migration. Not very attractive! You will probably have to re-write all interfaces. 
  • Define all migration requirements. Develop and test all migration programs and methodology. 
  • Consider running one or several full scale migration tests where you do everything but update the new PDM databases. Correct data in the old PDM databases after each test run based on the errors found or add new rules in the migration programs. 
  • Consider developing a strict time table for the entire migration and stick to it. Also, consider whether you will need a point in the migration sequence where you still will have the option to back out if necessary. 
  • Consider to split the education in two halves: Educate half the user community before the migration and the rest after. 
  • In any case: write a report containing all the problems and their solutions to be presented to the Steering Group. The report should also contain all the costs related to the migration.

There may be some more points to consider but you will no doubt come across these when you have started working with the migration problems. If nobody deals with these problems, they will certainly pop up in a very violent way at the end of the PDM Project. So, I recommend that there should be a group of people within the PDM Project that handles Migration and problems and solutions related to migration. Migration is certainly critical for the success of the PDM Project.

For your further reading on this topic: John Stark recommendations regarding PDM.