Migration from 2009 to 2015 -> Merging Objects

sas_fisch

Hi,

we plan to switch from NAV 2009 SP1 RTC to NAV 2015 CU6. We found the whitepaper with all the introductions for the data migration. At the moment we are fine with the steps there...

Now our questions are: What is the best / right way to migrate the objects? Of course we have many one changes in NAV 2009 SP1.

Regards
sas_fisch

mohana_cse06

You can use these powershell scripts to upgrade
http://blogs.msdn.com/b/nav/archive/2014/07/07/merging-application-objects-using-windows-powershell.aspx

sas_fisch

Thanks for the link!

I exported all objects (for each object type an separate file) from our Version, Vanilla / Cronus 2009 SP1 Version and from 2015 and put them in these folders:

MODIFIED -> 2009 modified by us
ORIGINAL -> 2009 Vanilla
TARGET -> 2015

For XMLPorts I get (Version MODIFIED and ORIGINAL) the warning:
"Begin expected."

Similar for Reports, there I get the warning:
"DATAITEMS is not supported in this version."

What did I wrong?

nbartie

For 2009 to 2015 I found the following steps get you to 2015:

Working folder = "D:\Merge"

1. Create TXT files (because 2009 does not support powershell object export)
1.1. Export MODIFIED.txt (6-0) to "D:\Merge"
1.2. Export ORIGINAL.txt (6-0) 'Cronus' to "D:\Merge"
1.3. Export TARGET.txt (8-0) 'Cronus' to "D:\Merge"

2. Powershell (this bit is fantastic 8) )
# Create the four folders ORIGINAL, MODIFIED, TARGET, RESULT
CD "D:\Merge"
New-Item -ItemType directory -Path .\ORIGINAL, .\MODIFIED, .\TARGET, .\RESULT -Force
# Split files
Split-NAVApplicationObjectFile -Source "D:\Merge\ORIGINAL.txt" -Destination .\ORIGINAL -Force
Split-NAVApplicationObjectFile -Source "D:\Merge\MODIFIED.txt" -Destination .\MODIFIED -Force #include new objects too
Split-NAVApplicationObjectFile -Source "D:\Merge\TARGET.txt" -Destination .\TARGET -Force
# Merge objects
$result = Merge-NAVApplicationObject -OriginalPath .\ORIGINAL -ModifiedPath .\MODIFIED -TargetPath .\TARGET -ResultPath .\RESULT -Force
$result.Summary
# Join into single file to import
Join-NAVApplicationObjectFile -Source .\RESULT\*.txt -Destination .\RESULT\all-mergedObjects.txt -Force

3. NAV 2015
Import all-mergedObjects.txt (not you may get issues with control ids etc, manually fix in the file until it imports)
Manually fix objects as per the results in the \Merge\RESULT folder look at the object.CONFLICT comments.

Hope this helps.

sas_fisch

Something is wrong

I did this steps and during:
Split-NAVApplicationObjectFile -Source "D:\Merge\ORIGINAL.txt" -Destination .\ORIGINAL -Force

I get the message:
WARNUNG: \Merge\ORIGINAL.txt (230134,5) DATAITEMS is not supported in this version.

When I look in the folder "ORIGINAL", I only see tables. So the error message happens with the first Report, it looks like the skript full stopped.

jglathe

Hi,
you cannot merge reports... they are completely different (or so, it's not worth the effort for the few bits that you can merge). These cmdlets don't support classic reports, I'd guess.
with best regards
Jens

sas_fisch

Okay if reports are not working, what is the procedure for reports?

jglathe

Hi,

sas_fisch wrote:

Okay if reports are not working, what is the procedure for reports?

From my experience so far:

1. All reports that are processing only: Create an "empty" NAV2009 database with all objects, no data. Open this database with NAV2013 development environment. Convert the reports with the "Upgrade report" function in the tools menu. Export the reports as .fob. Import them into your NAV2015 target. Compile / work out the errors, replace OCX with .net, the works.

2. All reports with a layout: Don't bother with conversion, start from scratch, reimplement them in NAV2015. If all your 2009 reports are RDLC already, you can try the conversion route like 1. I won't expect good results, though.

with best regards

Jens

fred69

Hi,
I still feel quite skeptical about any automatic merging tool. In my opinion, there are many situations where the automated process leads to strange results. Sometimes you won't get any error when compiling or running the application but you may get unexpected behaviours (wrong key leading to bad performance for example).
My opinion probably sounds old-fashioned but here is what we do : we first look for all the standard objects that have been modified (let's say <50000 or >99000000) and compare them one by one with the old standard version and the new standard version. We merge the changes on the new standard version (most of the time, the merging process consists of "copying" new fields or new code from the customer's old version to the new standard version) and import the merged text files one by one. Of course, before doing that, we have imported our full-specific objects (50000).
I usually say that we take 5 minutes per object (this is an average of course, you will sometimes spend 30 minutes on one object and just 20 seconds on another one but I always checked in the end this 5 minutes ratio and it was quite good). If you have 500 standard objects that have been modified, you may expect about 5 days in order to merge them. Of course the automatic process looks better... But, when you look deep into each object, you will probably see that there are things you can get rid off, you will ask yourself how you are going to deal with the UI changes between the old version and the latest one (how do you arrange actions in the ribbon, which picture can you assign to this specific action...), you will sometimes replace some wrong FINDFIRST statements with FINDSETs and so on...). In the end, you won't have missed a lot.

Of course, the Reports are not included in this old-fashioned solution.

Last thing, this manual merging process needs someone that can compare text files during 5 days, without being disturbed every 3 minutes, without committing suicide because of that at the end of the day and without looking at the birds through the window... If you don't have that guy, you'd better run the automatic process and wait for the problems to occur before solving them... If he has only seen (and merged) 40% of the changes that have been made, it's as if he had done nothing, you can start the process from the beginning again...

Courage !

sas_fisch

Thank you for all your replays, I will use the automatic way for a some objects. I will carefully check the result and then decide with way we will use.

kabroco

"
1. Create TXT files (because 2009 does not support powershell object export)
1.1. Export MODIFIED.txt (6-0) to "D:\Merge"
1.2. Export ORIGINAL.txt (6-0) 'Cronus' to "D:\Merge"
1.3. Export TARGET.txt (8-0) 'Cronus' to "D:\Merge" "

TARGET is your customized version, not 8.0.....
Modified is version 8.0