Best practice propagating NAV2013R2 changes to NAV2015?

greys
Member Posts: 29
Hi there!
We have a solution based on nav2013r2 and I already migrated it to nav2015 a few months ago, just to test & walk through the process of upgrading. I used the Powershell cmdlets and that worked very well. There were some 70 conflicting objects which I had to resolve manually. In less than a day, I ended up with a functional nav2015-database, which was very cool
In the past months however, development on the nav2013r2-version continued and now I've come to the point where I want to propagate all these changes to that NAV2015-database.
I'm afraid that when I use the microsoft release of NAV2013R2 as ORIGINAL, the current NAV2013R2 version as MODIFIED and the NAV2015-database as target and then run the compare-navapplicationobject cmdlet again , it will come up with these 70 conflicts all over again...
So my question is: what is best practice to propagate the changes of nav2013r2 to the nav2015 database, without having to go throught the complete process again (since the initial conflicts were alreay solved in the nav2015 database)?
Thanks for any tip on this matter!
Josh
We have a solution based on nav2013r2 and I already migrated it to nav2015 a few months ago, just to test & walk through the process of upgrading. I used the Powershell cmdlets and that worked very well. There were some 70 conflicting objects which I had to resolve manually. In less than a day, I ended up with a functional nav2015-database, which was very cool
In the past months however, development on the nav2013r2-version continued and now I've come to the point where I want to propagate all these changes to that NAV2015-database.
I'm afraid that when I use the microsoft release of NAV2013R2 as ORIGINAL, the current NAV2013R2 version as MODIFIED and the NAV2015-database as target and then run the compare-navapplicationobject cmdlet again , it will come up with these 70 conflicts all over again...
So my question is: what is best practice to propagate the changes of nav2013r2 to the nav2015 database, without having to go throught the complete process again (since the initial conflicts were alreay solved in the nav2015 database)?
Thanks for any tip on this matter!
Josh
0
Comments
-
I don't use the cmdlets due to this issue: https://grumpynav.wordpress.com/2015/01 ... correctly/
But if I were to use it in your scenario, I would assume it should be like this:
BASE: The custom NAV2013 version you based your first merge on.
MODIFIED: The new custom NAV2013 with all the new changes made after your first merge.
TARGET: The NAV2015 you made from your first merge.
That should ensure you only need to handle the actual modifications made sinde the first merge.Regards
Peter0 -
Thanks, Peter!0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions