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
- 305 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
Customizability vs Upgradeability
abton
Member Posts: 3
What are your views on the impact of customization on Navision's upgradeability?
For example, if my company spends $100,000 on customization, is it a major job to move that customization to the next version of Navision when it comes along? What's your guess as to the cost of that job compared to the initial cost?
For example, if my company spends $100,000 on customization, is it a major job to move that customization to the next version of Navision when it comes along? What's your guess as to the cost of that job compared to the initial cost?
0
Comments
The price will be lower if you make complete and detailed documentation for every customization.
Since (almost) nobody do it properly, cost may go up to about 50 %.
In some cases like : 2.60 to 3.XX it was easier to write it from the begining, than trying customization.
I would realy like to found out what will happen with 3.XX to 4.XX migrations.
Migration from 2.60 to 3.10 was approx. 20% done by the upgrade tools (which are build in poor quality) and the rest by searching and re-customizing.
For example: Your NSC changes some properties in a report or a database field - but there is no possibility to make an inline documentation.
During the upgrade you will lost this customizations and your own people will report some problems days or weeks after the system upgrade.
So if you pay 100000 $ for cutomization you have to pay either 50000 $ for documentation and 20000 $ for the upgrade or you can pay 30000 - 60000 $ for the upgrade with the well known trial and error tour.
The code system and the IDE isn't state of the art and the development process isn't supported like known in JavDoc or CVS.
Navision is making the upgrade process a bit more interesting by renaming some field names in the database - without documentation.
Buy a large sheet of paper, write down the words from navi-man "Avoid customization as much as possible" and put it on the wall in your office.
It's a horrible idea to upgrade to 4.00.
What supports this opinion?
How much contact have you had with 4.0?
Have you somehow tested the 4.0 version or the upgrade process from previous versions to 4.0?
Thanks
We have upgraded from 2.60 to 3.10 and from 3.10 to 3.70. Both times the same problems and both times the same announcements: Better code quality, better robustness and so on.
Both time have we paid the upgrade party! Both times some 10000 $ to search and (re-)programming of the customizations.
The 4.xx version can be very sophisticated but it isn't able to repair the structural problems of the 2.xx and 3.xx system and the organizational problems of the program developers.
Go to your NSC and spend a day of your life to discuss quality assurance during software development.
I'm sure, you will be ready after one hour. There are a few guidelines but no quality assurance and no lifecycle management and no software metrics.
If you want to say: Microsoft will enhance this business. Well. Have you ever upgraded from Office 97 to Office 2000 to Office 2003?
The main disadvantage is, that the customer has to pay this outdated development process.
http://www.sampioni.com/en/zasto_sampioni.htm
There is a cristall clear explanation why we all have problems in our everyday work.
I highly recomend it.
IT IS A TRUE STORY. :roll:
What is wrong with the Compare and Merge tool in the Developer Toolkit? I am told that makes upgrading easy, even with extensive customization.
Navi-man, do I know this company ?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
For this reason, I'd suggest that you develop you own ERP based on Navision as good as possible, and forget upgrades until 10-15 years. If I compare the latest version I know (3.1) and 4.0, I see no reason to upgrade, if you developed Navi into something really usable.
$100 000 for developments. Wow! That sounds like 200 days. Really a much. Why don't you just hire a Navision developer as an employee for $2000/month and will do everything in a year?
Do It Yourself is they key. Standard code might work - your code surely works.
$ 100 000 is not very exeptional for large projects in Navision.
for $ 2000 a month you won;t find a navision engineer over here, at least not one that is capable to do an implementation by himself. That is if you can find one.
If you lost custom development during an upgrade, that means that merging your current system into the upgraded one was not done correctly. It sounds to me like you tried to do the object upgrade yourself, where this really should be done by a solution center. The fact that this happened twice surprises me.
It takes me about 2 days to completely merge a heavily developed database from one version to the next. At my rate that would cost about $2000 (of course that is not the extent of the cost of an upgrade). If you had to pay $100000 to fix the problems from an upgrade then that is just wrong, but has nothing to do with whether or not you should consider upgrading.
RIS Plus, LLC
RIS Plus, LLC
This takes a lots of time to convert.
But fortunalely I don't have to do upgrades
you either a genius or have some very, very cool tools
Do It Yourself is they key. Standard code might work - your code surely works.
Must be a genius.
=D>
Bycicles, coffee shops... and now it's the third thing that makes think about moving to The Netherlands
Do It Yourself is they key. Standard code might work - your code surely works.
http://www.mibuso.com/forum/viewtopic.php?t=8729
Shall I translate for you
As for merging upgrades, I have some hints:
1) Never compare a customized object to an upgraded object - always a big mess.
2) If its a small fix, compare it to the standard, if it is a major upgrade, compare your modified objects to the standard.
3) WinMerge on SourceForge. It's very useful, and using Open Source tools will ease your feeling of guilt about pumping money into Microsoft with your work
4) Try to understand the logic of the changes, and take notes such as "copy this code from this trigger" , "copy these field"
5) Just do it manually by opening 2 Navi clients. Never try to merge in a compare tool, that's a big mess.
Do It Yourself is they key. Standard code might work - your code surely works.
This is true.
This should not be a problem in US.
Also not for relatively new NSC's.
The thing that bothers me is that as soon as somebody talks about his experience and the experience isn't quite so wonderfull, it's bound to be his own fault, it's never the fault of Navision.
A few weeks ago we had a consultant in here for another non-Navision project and that same guy was doing a Navision project at some other company. Because he was called on his cell phone quite a lot of times we were able to follow a bit. We heard jus the same problems as we had. The interesting fact is that this guys works for a company that used to write software for Data General systems. In this day and age, the only thing they get sold is an ERP application, so they decided to sell Navision and become an NSC. Actually, it looks like any software shop is becoming an NSC. At the rate we are going there must be a hundred NSCs in Belgium. Do you really think all these NSCs know how to properly develop in Navision ? I thik there are some huge upgrade disasters looming in the future, and all those companies that thought to save money by buying an ERP will in the end lose money big time.
The smartest thing I read here was The only problem with that is that sometimes due to accountancy legislation or the introduction of the Euro or any similar event you are forced to upgrade because the alternative is such a huge undertaking that it is almost like building the whole thing from scratch, with the big minus that you are developing in a crippled environment.
You can have the latest greatest Visual Studio with all the source safes and task control and code repositories at your fingertips, or all the open source and "I am smarter than everybody else" consultants working on your project, and STILL be in the crapper if the people working on the project don't know what they are doing.
If you do a Navision upgrade correctly then you *will* catch all custom development. It might take more than 2 days, but it should all be caught.
You are putting the blame of these screwed up projects square on Navision, and that is just not the case. I never ever said that Navision is the greatest thing since sliced bread, I just do not agree that the product is the cause of these issues.
RIS Plus, LLC
RIS Plus, LLC
Hi jesam,
Mostly it is not your fault. It is not your fault if your NSC has done a bad job with your customizations. I agree with you that there are a lot of people out there pretending to know Navision but not really knowing what they are doing.
With that said I doubt it would be any different if you got a really bad Java programmer to do something for you so that does not make Navision a bad product.
It is a reality of business that small to medium size companies do not want to pay for documentation. So the fact that you did not have any it is really just a fact of life and an implicit decision you made when you accepted not asking (and therefore not paying) for documentation. And therefore not something you can complain about it.
It IS somewhat your fault for choosing an incompetent NSC (there is no excuse for not doing your own research, doing client-site visits and asking for references or, even worse, falling for a cool sales pitch).
It is not fair to use as an example of upgrade 2.60 to 3.xx due to the architecture changes that happened after 2.60. With that said a brute approach to moving code over would not take me too long (not 2 days though I am not that good). I spend a lot of time to reevaluate code and see if it is still needed or maybe some new standard functionality could be used instead (remeber the goal of as few mods as possible).
And finally to the "no modifications" slogan. I develop by the rule "as little modifications as possible and use standard Navision wherever you can" . Maybe because I am a lazy person
If by any chance you take a hard look at your Navision and you do come up with the decision that you really could do without any modifications to Navision then again IT IS YOUR FAULT. It means you made a bad business decision. If you had spent more time researching products you were bound to find other products with same Navision out of the box functionality (or probably even more) for a lot less money. Navision's high price tag is justified by its famous flexibility but otherwise for out of the box functionality is not that great.
I am sorry for going on but I am tired of people bad mouthing Navision due to bad NSCs. In the hand of a good tailor a pair of scissors can create a really beautiful suit. In the hands of a dumb person a pair of scissors can hurt all around him and himself.
I had the honor and luck to work only with really good NSCs so I can vouch they are out there. I always say that finding an NSC is like finding a dentist. It is painful to try one, you don't find out immediately they are bad (unless they are really bad) and it costs a lot of money to keep trying. But that does not mean dentistry is useless or that you do not need a dentist.
But if you think this is bad go talk to some of the people who have tried (and maybe succeded) implementing SAP.