Upgrade without keeping modifications

AlexWiley · 2010-01-05

Hello everyone, if you were going to upgrade (in this case 4.0SP2 -> 2009 SP1) but did not want to keep any of the modifications in the previous version, what would your ideal path be? I can think of three options:

1) Do a full upgrade including the modifications then once everything is in 2009, remove the custom code piece by piece.

2) Copy the 4.0 DB, remove the modifications, then use the upgrade toolkit.

3) Massage all custom data out in SQL and copy only the required data into the 2009 database.

I have a feeling #2 would be best practice. #3 would be a lot easier, but I have never done it before, so I'm wondering about unforeseen consequences. For further info, there is no inventory here, so just g/l, customer, vendor, bank, and invoice data. Input is appreciated, as always!

ara3n · 2010-01-05

I would do this way, which is like your 2nd step.

1. Write a processing report to blank all the field in the 5K range. You can find these field by creating a form with source table FIELD.
2. Delete all 50K range objects.
3. Load 4.0 NAV Standard objects.
3. Upgrade to 2009

Alex_Chow · 2010-01-05

Or you can just migrate the custom fields without the code and do an upgrade. Then clean up the field when you're not under a time constraint.

matttrax · 2010-01-06

I think both of these are valid. I would remove the data first if time is not against you. Doing it later just means extra work of merging the customizations and then later deleting them (well, I guess you can just import base objects). But merging is a pain. I tend to go the path of least resistance when possible.

Alex_Chow · 2010-01-06

matttrax wrote:

I think both of these are valid. I would remove the data first if time is not against you. Doing it later just means extra work of merging the customizations and then later deleting them (well, I guess you can just import base objects). But merging is a pain. I tend to go the path of least resistance when possible.

No merging is necessary. Just use the standard merge functionality during the object import.

AlexWiley · 2010-01-13

ara3n wrote:

3. Load 4.0 NAV Standard objects.

Can I ask why this is important to do if the original object is having the modification removed? This step seems to be causing me lots of issues. I remove the custom field/data, then import the original 4.0 object, and then the object won't compile- for example doing this to the Purchase Header gave errors from Sales Tax fields to PostCode.ValidateCity commands, all native and nothing that was touched during customization.

ara3n · 2010-01-13

Do you get the same error when you compile the object in a 4.0 cronus database?

Make sure you load all 4.0 the objects.

Upgrade without keeping modifications

Comments

Categories