Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K 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
- 314 Dynamics CRM
- 110 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
Technical upgrade from 4.0SP1 to Nav 2009
navuser99
Member Posts: 14
We are looking into doing a technical upgrade from 4.0SP1 to Nav 2009. We are using the navision proprietary database. Can someone provide the steps to do the technical upgrade? Are there any issues that I should be aware of when doing this? Common pitfalls, etc?
0
Comments
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
2. Re-install the Navision database server on the server from the NAV2009 installation CD.
3. Install Navision on everyone's computer
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
I'm going to move NAV to a new server that has W2008 R2 on it (to test first). I was assuming that I would do a backup of the production 4.0 db, install 2009 exe's on the new server and then do a restore of the 4.0 db backup?
When you say open the database directly with a 2009 exe....is that from a client or a server exe?
|To-Increase|
Upgrading a large classic database with 4.0 code to the NAV 2009 SQL Server is possible but a good idea :shock:
I was under impression this was a bad idea because of the improvements in the 6.1 code and all the underlaying sql settings..Anyone?
Investigating further I asked two different partners and one says 3 days to do a technical upgrade and one 6 days.
It's a database of 50gb. Restoring will fail if some field is wrong, so I guess this will take the longest time.
Haven't had too much complaints regarding executable upgrades thus far. In SQL, you just have to monitor the performance and tune it accordingly.
3-6 days for executable upgrade seems excessive. I show their internal IT department how to do it, and they do it themselves. Haven't had one failed executable upgrade yet doing it this way yet.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Thanks for your help. My customer wants a fixed price and anything happening after this must be included. Did some searching on this website and I am adding extra time for the following:
1.
To get the export to excel, word working you must update code and tables.
- Add 1 day.
2.
From here: viewtopic.php?f=23&t=45692&hilit=executable+upgrade
There is code in 4sp1 that will not work with 5.00 executable and can give errors. For example the MAX function in FlowFilters works differently, and there is an issue in some builds with the way INSERT(TRUE) works.
- Add 1 day.
3.
There is a speed issue with some indexes. Brummel wrote a book about this.
Add ? days.
My own guess is:
2 days for finding and updating all wrong database fields which don't work in SQL (it's a 50Gb database). Testing dataports/Import code, Testing Invoicing, ordering, backup.
2 days for updating the server + nas + clients
2 days for support and change code afterwards
Please hit me if I got this wrong.
I think that's a reasonable quotation. Especially if it's a fixed price.
With best regards
Jens
---
I am here: http://maps.google.com/maps?ll=52.555332,13.094402
True, 4.0SP1 was one of the worst ever versions of NAV on SQL Server and all the updates that came between that version and 5.0 SP1 made it terrible for all those involved.
Also true is that 2009 R2 is one of the most stable versions on SQL Server and most issues that we had in these days are solved by Microsoft in the binaries of both NAV and SQL Server.
What remains is the application; how you use it, how it is modified, etc.
If you have a 50-100GB database that uses warehousing and/or MRP you definately want to do some testing. Having a warehouse that cannot ship can easily kill any midsized company.
The rule is that there are no rules, at least no general ones to follow.
The safest way to go is to have someone analyse your database and does a risk analysis of your specific system. This can be done best by the company that has implemented your system and the people who have done that. If they are not available then you might want to hire a specialist, but they will need to learn your company and system first.
RIS Plus, LLC
I am guessing then that you didn't do too many SQL installs on either 2.5 or 3.01 or 3.60A then :shock:
I have done 5.x to 2009. We have a competitor partner who is offering a fixed price of 4 days to do a technical upgrade. Im looking for arguments why this upgrade can go wrong doing it fixed price and with someone without knowledge of the implemented database and without extra days of testing.
Where these worse? I mean the issues with SQL2005 and parametersniffing where just terrible.
These old versions with SQL2000 were more understandable.
Anyway, I am glad that we are no longer at the point where just "SQL" stands for "issues" but stands for "stable".
Let them do it fixed price.
2.5 was so bad that when they finally got a service pack that worked they gave it a new version number 2.6, and 2.6 went up to 2.6H if I remember rightly. One of the biggest issues with 2.5 is often some users couldn't see changes that other users had made, they would have to log out and back in again. Not nice in a multi-user system. 3.01 was just a night mare but that was both native and SQL but SQL added lots of stuff to the picture. Up till then though those were systems I was called in to fix. The first SQL install I did my self was 3.60A, so I guess that's why I found it the worst version of all. Eventually we had to make a system to abort the go live and wait for 3.70. 3.70B was good. It was a bit slow, but it wasn't until 4.0sp3 Cu9 that they got a version as stable as 3.7B
Very true.
In this case though we were in the middle of a Go-Live, and the company got bought out by a public company just as the SOX laws were introduced, and it was near impossible to get SOX compliance on native and 3.60A was all that we had. In the end though without Change Log we couldn't get the SOX sign off anyway, so we had to wait which was quite lucky.
Back on topic... I agree with Mark, if you are concerned, then let the other partner do it. Otherwise go and match the 4 days, and expect to lose money on it, but gain in learning.
I don't agree with this.
http://dynamicsuser.net/blogs/singleton ... n-use.aspx
We say No, the other partner does the job, things go wrong, we can resolve it. We can´t tell we told you so because the customer is always right..
We say Ok, we do the job for the same money, things go wrong, we can resolve it. We can´t invoice it because the customer is always right..
The worst outcome for you is telling the customer it can go horribly wrong and then the other partner comes in and does a great job.
Tricky politics huh
RIS Plus, LLC
Sometimes I have long discussions with my customers where we listen to each others ideas and expain our views. Often we come up with plans that are not even close to the orriginal ideas we both had to start with.
Tell your customer the truth, tell them that there is a fair chance that the project is a 4 hour job their IT guy can do. Tell them that there is a risk that is might be 40-80 hours. Explain them why. Hell, show them this thread.
Then ask them what they want you to do.
Quote it for 3 days, then eat the cost if it's over.
This is the only way you can be sure of the pitfalls. On the next deal, you'll be more knowledgable.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
One thing further on this. From my experience, when customers focus more on the price than the work itself, you're going to run into more problems down the line.
You might want to consider if this kind of headache is worth it for you guys.
I do realize that it's a down economy right now, so the decision may not be that easy.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book