Skip to main content

Dear All,

 

We are currently working on an IFS upgrade project to transition one of our IFS customers from IFS 9 UPD 14 to IFS Cloud. We have completed our first upgrade iteration and have upgraded the customer to IFS Cloud 23 R1. The customer belongs to the telecom sector, and work orders from IFS applications are the main area they are utilizing.

 

During this initial iteration, it took 78 hours and 20 minutes to execute the main upgrade script. Out of this total time, 72 hours and 52 minutes were spent on post-installation data file deployment. Within this time frame, the work order module related files took up 69 minutes and 37 minutes. Below are the files that took the most time:

  • POST_Wo_UpgradeToTaskFramework.sql:                                           16 hours and 48 minutes
  • POST_WO_UpdateHistAllocations.sql:                                                   2 hours and 48 minutes
  • POST_Wo_UpdateJtTaskPlanning.sql:                                                   46 hours and 26 minutes
  • POST_WO_CreateAssignForDefTask.sql:                                                1 hour and 50 minutes
  • POST_Wo_UpgradeTransactionsToTaskFramework.sql:                    27 minutes
  • POST_Wo_UpgradeOthersToTaskFramework.sql:                               31 minutes
  • POST_Wo_UpgradeEquipStructCostToTaskFramework.sql:             23 minutes

 

Although I'm not fully familiar with the functionality of all these scripts, I am aware that transitioning from IFS 9 to IFS Cloud brings significant changes to the work order area, and with the amount of data involved, it may take some time. However, I find the durations of two of the scripts particularly concerning:

 

POST_Wo_UpgradeToTaskFramework.sql:             16 hours and 48 minutes

POST_Wo_UpdateJtTaskPlanning.sql:                     46 hours and 26 minutes

 

This is an exceptionally long duration, and we cannot plan a go-live cutover with such massive time taken by just two scripts, accounting for almost 80% of the upgrade script. I have already reported this to IFS via a standard support ticket to seek their feedback. However, I am certain that our customer may not be the only one facing this issue. Therefore, through this post, I kindly request to know if anyone else has experienced the same and what kind of tips and tricks were followed to reduce this time. For example:

 

  • Has anyone found these scripts to be optimized in 23 R2 or planned for release update in 24 R1?
  • Has anyone reduced this time by allocating more resources to the upgrade process, such as CPU or improving disk IOPS, etc.?
  • Are there any functional setups that can be done before the upgrade in the source database in the work order area, so that the post-data installation time doesn't take as much time? In other words, is there anything that can be done prior to the upgrade to reduce this time?

I would greatly appreciate your feedback and knowledge sharing on this matter.

 

Thank you.

Hi,

We are facing the same issue and this customer is upgrading from App9 UPD17 to IFS Cloud 23R2SU4. We found that upgrade execution is stuck on timestamp 3 of  POST_Wo_UpgradeToTaskFramework.sql for more than 18 hours. I have raised a case. Do you have any update on this ?

Thanks,

Isha

Hi,

We are facing the same issue and this customer is upgrading from App9 UPD17 to IFS Cloud 23R2SU4. We found that upgrade execution is stuck on timestamp 3 of  POST_Wo_UpgradeToTaskFramework.sql for more than 18 hours. I have raised a case. Do you have any update on this ?

Thanks,

Isha

 

Hi @Isha 

How are you? Hope you're doing fine 😊

Sorry, I don't have a concrete answer yet. IFS Support is still investigating. I'm think (may be) these scripts take time due to the amount of data, but there should still be a solution to make them faster, or an alternative approach to execute them as batches after Go Live. Otherwise, we cannot plan the Go Live cutover. Did you get any feedback from IFS or another solution for this?

Best regards,

Amila

Hi @AmilaF,

I had an issue with POST_Wo_UpdateJtTaskPlanning.sql (Apps10 to IFS Cloud 23R1 GA).The issue was with Timestamp 5 in my case. I got a customized fix for that particular customer which reduced the execution of the script from 8hrs to few minutes.

At the time, RnD told that the fix is not planned for any SU and it is unique for the requested customer’s data. I hope you can request something similar

Regards,
Nishanth

Hi @AmilaF,

I had an issue with POST_Wo_UpdateJtTaskPlanning.sql (Apps10 to IFS Cloud 23R1 GA).The issue was with Timestamp 5 in my case. I got a customized fix for that particular customer which reduced the execution of the script from 8hrs to few minutes.

At the time, RnD told that the fix is not planned for any SU and it is unique for the requested customer’s data. I hope you can request something similar

Regards,
Nishanth

Hey Nishanth,

Thanks. Indeed, I'm not looking for a general fix that matches all situations, as I know in our customer's case, it may involve a lot of data. We might need to implement some functionality to reduce the amount of data handled during the upgrade. Thanks for your input.

 

Kr

Amila

 

Reply


Terms & ConditionsCookie settings