I have a book case here…on one server we have Nav 4.1 native dbms, 40 users, 64GB, on another server Nav 5.0 native dbms, 40 users and 46GB (a company we bought later). Knowing we’re going to go on with more acquisitions of company already running Nav I’m considering moving both existing Nav versions on one SQL server (I know it & use SSI & reporting) with 2 databases (and eventually more) , utimately Nav R 2009 on SQL 2008. What would be the optimum path to reach this goal ???
I’ve always adopted the rule divide to rule…or reduce risks by dividing a complex task into multiple simple tasks ! so I would prefer moving one company at a time and I would prefer moving to SQL then upgrade version, but could be a problem for version 4.1 that doesn’t support SQL I learnt
What would you suggest ? what are the pro & cons of putting all eggs in one DBMS ? Should we upgrade version before moving to SQL or SQL then version ?
basically its important to know that in the Natvice DMBS, all the versions from about 4.00 are the same. In reality there have been no significant cahnges to the Native db for a long time. So it really does not matter which version you are on, the issue will be which version you move to. When you say 4.1 (there is no such thing as 4.1) I guess you mean 4.00 SP1, which does exist in SQL, but is a really bad version that you do not want to go with. In your case the biggest issue moving from Native to SQL is going to be performance. In that you have two possible paths to go, pre Dynamic Cursors or Post Dynamic Cursors. In your case, 4.00 Sp3CU9 and 5.00 no service pack no hot fixes would be your PRE options. The advantage here is that the performance hit would not be quite as bad as moving to the newer version. The issue is that you will have to move to the newer version one day, and then have to tune again.
I don’t see any advantage in doing a multi step upgrade in your case (though every implementation is different, and I am basing this on the limited information posted here.)
Thus my advice will be to go all the way, upgrade the databases to 2009R2 SQL Classic. I don;t think it matters which DB you do first, the issues are going to be similar, though one issue is that 5.00 was tuned for Fast Forward cursors, and thus you will have to remove all those changes before moving that one across, so its probably better to start with the 4.00 database first.
Thank you to pay attention to my post. I’m not sure whether you get me right on the fact that I do not plan to merge the existing databases into one SQL instance, I’m considering having 2 instances on the same SQL Box because actually each has its own customizations (I do not want to embark into objects renumbering/manipulation as one Nav consultant explained to me), and new companies to come may have their own customizations as well, does that make sense !?
To be more precise we have Nav 4.0 SP2 and Nav 5.0 SP1. It is not that I’m not happy with the actual set up, but I don’t want to lag behind in term of versioning & support on the Nav side, while moving to SQL is only motivated by performance issues (for the Nav 5.0) we experienced such as : tables locking during peak periods and slow reporting. We recently installed a table optimizer product (from Expand IT) to help and are closely monitoring with users the results, in the light of which we’ll consider or not moving to SQL.
Option 1
Since Nav 2009 can work with C/Side Native dbms then one option could be to upgrade both Nav to this version as a first step, then move on one SQL box with 2 databases instances at a later stage (if recommended). What do you think, upgrading for upgrading better upgrade to the newest version then we’re ok for a couples of years ?!
Option 2
Since Nav 5.0 have an extended support end date up to 2017 we could consider as a first step an homogenization of our Nav version by upgrading both to Nav 5.0 SP1 Update 2 on their existing box using C/side native dbms. This should be an easy move but still will require some investments. Then the next step would be to move both databases on one SQL Server Box (2 instances) and at a later stage upgrade to the latest Nav version?! The advantage here is that we’ll already be on SQL when moving to the newest version under a 3 tier architecture but we’ll have to bear the cost of 2 consecutive upgrades over time.
My favorite is option 1, yours ?! I find multi step upgrading (Nav version then SQL) less risky in term of debugging issues that can result from one or the other upgrade.
Yes I fully understood this, but I think the “Nav Consultant” you spoke with does not. Basically you can have as many databases as you want on one SQL server, each running different versions of Navision with different objects. There is no need for multiple instances of SQL, and in fact multiple instances will make the system slower and more difficult to manage. So there is no need to merge.renumber objects, either you misunderstood the consultant or the consultant doesn’t know Navision too well.
As to option 1 and 2, I would still stick with my recommendation above. The key issue here is that there is virtually no change from 4.00 to 2009 for the classic client, so its not really an upgrade at all. Thus I would simply move direct to SQL 2009 and do all the work in one hit. The actual conversion process will take about 2 days per database, Say a week in total, then the big issue is the performance tuning. You say that on the 5.0 you are already having performance issues that need to be addressed, so you are going to have to do that tuning anyway. i just don’t see any benefit in the multi step process, and it will probably double the cost. Use the money you save to tune the databases.