Skip to main content

Hi,

after one year of IFS EAM usage we realized that initially created hierarchy and equipment codes are not complying with our needs and we need to change whole hierarchy  and equipment codes but retaining all PMs, WOs, Routes, Documents, Measurements, etc populated during one year.

What could be the possible options of performing this operation?

Or the only possible way is to perform mch_code and belongs_to values replacement all across the database ?

What version of IFS?

Can you offer some more illustration of the change you are hoping to make - what do the IDs and hierarchies look like before and after?

This would be a very complicated script - some parts can be done via standard business logic - for example, you could try taking a work order, reopening it, pushing it back through statuses, then try to change the object ID to the new one.

But a lot of this is outside of standard business logic and would be a big undertaking, script-wise. 


Thank you for the answer! We are using IFS 10 upd 8.

Example1 of old and new code:

Old code:IL.IL.PO.L7.ATSL-SK.0.ZU  Old belongs to:IL.IL.PO.L7.ATSL-SK.0

New code:CBG.GP.IL.IL.PO.L7.ATSL-SK.0.ZU New belongs to: CBG.GP.IL.IL.PO.L7.ATSL-SK.0

Example2 of old and new code:

Old code:IL.IL.PO.L7.ATSL-EKA.DAS2SL.ZM.DR  Old belongs to:IL.IL.PO.L7.ATSL-EKA.DAS2SL.ZM

New code:CBG.GP.IL.IL.PO.L7.ATSL-SK.0.ZU New belongs to: CBG.GP.IL.IL.PO.L7.ATSL-SK.0

   

I don’t Think you can manage this in anyway in the application. Even performing updates on DB directly won’t do as mch code is part of the key in object tables. 
 

I mean you cannot change a object id in the application. You can create a new and scrap the old but not delete the old if it has any transactions connected to wo, task, cost, anything. 

 

next bit would be changing object Id on historical work orders after re-opening them, well if they are connected to pm actions you would not be able to do that either. 
 

one option would be to create a new site, create the things you want properly and “transfer” old records to the new site. And by transfer I mean recreate under the right information the way you wanted. Problem is EAM is seldom the only part of Ifs in use hence finance, procurement etc will likely not bother with a new site. 
 

the only option I see is performing updates on the db and here you have to be really really careful. And I am not sure how you will get around the key issue In object tables. 
 

I am very eager to hear what will happen
 

 

 

 


I am very eager to hear what will happen

Dear Julian, 

thank you very much for your comment. Will definitely share results of the migration procedure. 


Hi,

I think this is a reoccuring issue for most EAM installations. We’ve gone so far as to make a customer adaption handling this scenario.

This customization is installed on several customers in Scandinavia.

We have also invested in IFS Asset Design to get further control of our asset hierarchy. Wether this pays off for you is really dependant on the level of change in your assets…

Best

Anders


I don’t Think you can manage this in anyway in the application. Even performing updates on DB directly won’t do as mch code is part of the key in object tables. 
 

I mean you cannot change a object id in the application. You can create a new and scrap the old but not delete the old if it has any transactions connected to wo, task, cost, anything. 

 

next bit would be changing object Id on historical work orders after re-opening them, well if they are connected to pm actions you would not be able to do that either. 
 

one option would be to create a new site, create the things you want properly and “transfer” old records to the new site. And by transfer I mean recreate under the right information the way you wanted. Problem is EAM is seldom the only part of Ifs in use hence finance, procurement etc will likely not bother with a new site. 
 

the only option I see is performing updates on the db and here you have to be really really careful. And I am not sure how you will get around the key issue In object tables. 
 

I am very eager to hear what will happen
 

 

 

 

Hi Julian,

sharing migration results as promised.

After all we decide to take surgical approach and performed code replacement in the database. We've been lucky, because this procedure was performed along with with upgrade to the newest version and data migration.

70k objects data together with all accompanying information (WOs, WTs, PMs, etc) were updated in few hours thank to prepared scripts and procedures. 

Now we are two months in prod, seems no data were lost.  


Reply