Length of 4.03 -> 5.01 upgrade

Cem_Karaer

Hi all,

We upgrade one of our customers from 4.03 to 5.01. We made the merge of all objects, finished step 1 data preparation & conversion and imported the customized 5.01 objects to the converted database. But the last step takes much more time we guessed.

There are 2 years of data with 50 GB and 4 active companies. Step 2 data conversion takes nearly one day for only one company. It will be completely unacceptable that the upgrade take 4 (or more) days to complete.

What can be done to speed up the process?

matttrax

You'll need to go through the code and see what really needs to be executed and what doesn't. For example, I had an upgrade with a Value Entry table with about 10 million records. The toolkit would have checked every single one of them (at about 1 second each) even though it didn't need to.

You can also upgrade half the companies one weekend and half the next.

Cem_Karaer

matttrax wrote:

You'll need to go through the code and see what really needs to be executed and what doesn't. For example, I had an upgrade with a Value Entry table with about 10 million records. The toolkit would have checked every single one of them (at about 1 second each) even though it didn't need to.

You can also upgrade half the companies one weekend and half the next.

That's a good news matttrax! But will it cause any problem that users will create new records with new logic resulting new pattern but old records are still in old pattern? For instance what if a posting requires some data according to the new logic in old records. Assume that there will be an item charge on sales that will be applied to a sale shipped one month ago, which will require some new data on the shipment line. I would prefer not to upgrade if something like it happens!

matttrax

I may have not explained the situation correctly.

In my case there was really no data to insert or change during the upgrade. I think some field had been moved between tables involving service management, which we don't use. That didn't change the fact that the code was still looking for that data and had to look at every value entry to be sure.

You may have the same case. Look at the code and the data. Is the code actually changing anything? It'll take some time to figure it out.

Cem_Karaer

There is a "Document Line No." field added to Item Ledger Entry and Value Entry. The primary reason why the upgrade takes so much time is that it updates every each record of item ledger entry and value entry with related posted document line. I think that it is not an unnecessary information and that upgrade must an atomic process.

Could it be possible that we make step 2 data conversion in four days or whatever for two years of data in an test environment while users still use 4.03 database and load 4 days of data to the test database and do partial data conversion on them and then finally make 5.01 test database as the live system?

matttrax

That is another solution. Back fill as much of this data as possible. You do have to pay special attention, though. You don't want to accidentally miss and records, but you don't want to waste time processing any records more than once.

I recommend only pre-processing entries for closed accounting periods, personally.

David_Singleton

cemkaraer wrote:

There is a "Document Line No." field added to Item Ledger Entry and Value Entry. The primary reason why the upgrade takes so much time is that it updates every each record of item ledger entry and value entry with related posted document line. I think that it is not an unnecessary information and that upgrade must an atomic process.

Could it be possible that we make step 2 data conversion in four days or whatever for two years of data in an test environment while users still use 4.03 database and load 4 days of data to the test database and do partial data conversion on them and then finally make 5.01 test database as the live system?

This is a question you need to ask yourself. How many times have you done it before? How experienced are your team with partial upgrades? How did you resolve the last upgrades you did.

If you have not yet done 5 or so upgrades like this then you probably don't yet have the experience to start experimenting. So get some basic upgrades behind you first before experimenting on this customer. I am sure that if you were experienced enough your questions would be very different to the ones you posted.

Cem_Karaer

David Singleton wrote:

cemkaraer wrote:

There is a "Document Line No." field added to Item Ledger Entry and Value Entry. The primary reason why the upgrade takes so much time is that it updates every each record of item ledger entry and value entry with related posted document line. I think that it is not an unnecessary information and that upgrade must an atomic process.

Could it be possible that we make step 2 data conversion in four days or whatever for two years of data in an test environment while users still use 4.03 database and load 4 days of data to the test database and do partial data conversion on them and then finally make 5.01 test database as the live system?

This is a question you need to ask yourself. How many times have you done it before? How experienced are your team with partial upgrades? How did you resolve the last upgrades you did.

If you have not yet done 5 or so upgrades like this then you probably don't yet have the experience to start experimenting. So get some basic upgrades behind you first before experimenting on this customer. I am sure that if you were experienced enough your questions would be very different to the ones you posted.

It's a right conclusion David. We have exactly no experience of upgrading a 4.03 live system to 5.01 with two years of data. For that reason I ask those kind of questions!

David_Singleton

cemkaraer wrote:

It's a right conclusion David. We have exactly no experience of upgrading a 4.03 live system to 5.01 with two years of data. For that reason I ask those kind of questions!

Then I would recommend you contact a professional upgrade center like Liberty Grove. Doing something like this yourselves is very risky if you have not done it before.

Cem_Karaer

Thank you David.