Hi, We have a customer that has a Navision 1.x SQL Database (450 MB, 1 user) and wants to upgrade it to 3.70 SQL. He can’t provide us with a Navision Backup of his database, because the Navision backup doesn’t work. He told me that he ran a maximum test on the database and that all was OK. He will send us a screenshot of the error message he receives when he runs the Navision bakcup. In the meanwhile, he sent us a SQL backup of his database that I sucessfully retored on our server. He uses Navision only on one machine and just to manage Fixed Assets. He is asking us to give him a quote for this upgrade. My questions are : -Can we do an upgrade from 1.x SQL to 3.70 SQL ? -What are the risks of this operation and the steps to do it ? -What are the constraints ? -What must we put as assumptions in the quote to protect us against any overflow (data corruption, ? -If you had to prepare the technical part of this quote, how many hours would you put for data analysis and for the migration itself ? Thank you in advance Malek
It really puzzles me how he can run Navision 1.x SQL, as the SQL server option wasn’t introduces until version 2.5.
Run away … run away (A bit of Monty Python there. [:D]). As Lars points out, the client is NOT running on 1.xx Navision SQL. Though they could be running thier own SQL backend. I had a couple of clients running 1.3 Navision with some of the data on a SQL 6.5 backend. (That was fun and a much longer story). My guess is that the client has a SQL or more likely an Access database on their local computer that they use for reporting, and someone has a link using OCXs, or more likely a simple dataport that populates from Navision. The other option is that it is a 1.2 object set on a 2.5 SQL server. In any case haveing said all that. I would NOT do an upgrade. Treat this as a new implementation, Install 3.70, and dataport all the exsitng data across. It will be cheaper by a long way, an much safer for both you and the client.
I just completed an upgrade from 1.2 to 3.6 - its the same as any other upgrade - it just depends on the number of customizations and the modules involved. THe one I just completed was pretty standard GL,AP,AR, and IM - so it wasn’t too bad. Going from 1.2 to 3.6, you do have to upgrade to 2.00 as a mid-step. So definitely build in some time to do that. Other then that, I really didn’t run into any specific problems - probably one of the easiest upgrades I’ve been involved with. (which has everything to do with the client and their customizations and nothing to do with 1.2-> 3.6).
Hi Daniel, you probably missed the point here … there is no such thing as Navision 1.x SQL, so when there is a problem upgrading from a product that does not exist, that gives a general hint of the direction of the problem.
I must admit I think Davids approach is probably the best. A fresh install has go to be worth it since the modifications that have been made to 1.xx may well have been superceded and the product as a whole is markedly different so a clean look at the customers business and their processes and how they can best be fitted into Navision has got to be overdue. However if they decide against it then as long as you do the install in a couple of jumps following the processes that you would have done if you had done the upgrade over time, that is the Upgrade from 1.x to 2 and then the upgrade from 2.0 to 3.7SQL, I cant see that it would be a problem. Its just why spend the time doing a long convoluted upgrade when that time could be better spent providing more value by effectively looking at it fresh. Upgrading a product that doesnt exist thats a bit like knitting with eels isnt it?
Thank you for your suggestion David, I think it’s the best way to do it. But what about the differences of table structures between the 2 databases. Some tables may have disappeared from v1.x to 3.7, some others slitted into 2 tables…How to deal with problems like that ?