Remove huge production add on from NAV2009R2
thomast
Member Posts: 102
Hi all you clever people,
How should I go about removing a huge production add-on from NAV2009? Its a production add-on with more than 300 custom tables and modifications to more than 250 standard nav tables. It even has its own BOM structure - basically it boycuts the entire manufacturing functionality in std. NAV.
My customer has used this module for a year but wants it removed but I am very concerned about overwriting the entire database with standard NAV2009 objects! For example, this module (which I do not know very well myself) could have created data all kinds of places in NAV and If I force std. objects into it, I'm afraid of being haunted by strange errors for the next couple of years.
What do you think? Is it possible to remove such an add-on or would a reimplementation be better?
Thanks!!!
Thomas.
How should I go about removing a huge production add-on from NAV2009? Its a production add-on with more than 300 custom tables and modifications to more than 250 standard nav tables. It even has its own BOM structure - basically it boycuts the entire manufacturing functionality in std. NAV.
My customer has used this module for a year but wants it removed but I am very concerned about overwriting the entire database with standard NAV2009 objects! For example, this module (which I do not know very well myself) could have created data all kinds of places in NAV and If I force std. objects into it, I'm afraid of being haunted by strange errors for the next couple of years.
What do you think? Is it possible to remove such an add-on or would a reimplementation be better?
Thanks!!!
Thomas.
0
Comments
-
Removing such big add-on seems impossible to me.
Reimplementation for sure.
You have to go through all processes at the customer site and see how standard NAV has a fit or a gap.
Tino Ruijs
Microsoft Dynamics NAV specialist0 -
I agree.
You could look at this as a migration, and take the opportunity to move them to the current release if they are going with standard.David Machanick
http://mibuso.com/blogs/davidmachanick/0 -
I agree too, fresh and clean, what can be better0
-
Hi,
I have done such a transplantation once. What you do is salvage all transactions without the item-related part. You also throw away all fields that you don't want to keep. Basically you create a new (preferably tested) codebase, and a cutting toolkit. Set up - cut - backup - import into new codebase.
with best regards
Jens0 -
Holy crap - 300 custom tables? That's a massive add-on! The amount of time to deal with all the data issues (including custom fields in all the modified base tables) could be a nightmare. I'd approach this one as a reimplementation on base NAV myself.Rob Hansen
http://www.epimatic.com0 -
Thank you so much guys!!! Re-implementation it is!0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.8K 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
- 327 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
