Howdy, Stranger!
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
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 304 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
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
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.
Peter