Suppose you had an organisation which had c.50 NAV databases, all of which are currently on NAV 4.0 SP1 Server and NAV 4.0 SP2 Clients on a SQL Server 2000 SP4 DB. Suppose that 48 of those databases were geographically remote and used flat file transfers to provide the ‘head office’ database with transactional updates, and that ‘head office’ sends flat file updates back, including transactional records.
Suppose you were considering your migration options.
If, for various reasons, it turned out that some of your databases needed to stay on SQL Server 2000 SP4, what issues could you foresee if it was decided to migrate the 48 remote sites to either:
( a ) NAV 4.0 SP3 client, NAV 4.0 SP3 Server, on SQL Server 2000 SP4 DB; or
( b ) NAV 5.0 SP1 Client, NAV 5.0 SP1 Server, on SQL Server 2000 SP4 DB
while migrating the head office database to:
( 1 ) NAV 2009 (with SP1 when it comes) on SQL Server 2005 or 2008?
What does your partner say about this? I would personally stay away from any type of mixed implementation unless I would absolutely have to, and have the same version everywhere. It’s going to be a nightmare doing object management, development, and any other type of adjustments, applying hotfixes and updates, not to mention that those come with different code bases and work differently.
It was actually suggested by our partner as an option.
I (a Business Analyst) immediately shuddered at the thought of the complexities of transferring transaction data between one and the other. So I thought I would ask here for opinions on the technical challenge of this approach so I could push back with some “but have you thought about this…” things.
Well, all in all this scenario should be discussed in detail … why are the databases forced to stay on SQL 2000?
If those db indeed need to run on SQL 2000 you should stick to 4.0 SP3+ (most recent version) as 5.0 and up are designed for SQL 2005/2008 and you might encounter several issues with SQL 2000.
Don’t dismiss the idea out right. For sure its is something you should at least evaluate.
I am currently working with a client in a similar situation, though they have quite a few more databases than you, but otherwise similar concept. Ultimately we have found that short term getting all the databases onto the same NAV and same SQL versions is very important. I would say even more important than synching the objects. But long term you really want to get a common object strategy in place.
I also just got back form another client last week, that is also planning similar, (only about 20 databases though) and in that case we will be running probably 3 or 4 sets of objects, but everything will be on 2009 sp1 SQL 2008.
In both cases the client will be using VM Ware one is using blades the other on one big machine.
Once its all in place, the big issues become managing them and performance. Be prepared to have a small team just to manage VM, SQL and all the NAV versions. It will take a lot of people to run this, BUT a lot less than you would need at each of 48 locations.
Having said this, I have also worked on projects where consolidation just did not make sense, so its critical that you review all the options carefully and in the end review the total cost of ownership on both scenarios.
By the way, forget NAV 2009, this is not a version to upgrade to, its a version for new clients. If you are upgading then wait for SP1. In any case sp1 will be out long before you are ready to make this move.
The remote sites may be able to run on a later version of SQL Server, but they are currently using a document management system which will not migrate beyond SQL 2000 SP4. Some of those sites have limited physical space, i.e. adding extra servers is a very complex proposition. For various reasons we may or may not be able to run SQL 2000 and SQL 2005/2008 on the existing boxes, so it is possible that with the existing architecture (distributed databases at the 48 sites) that the costs of changing those databases from SQL Server 2000 to a later version (i.e. upgrading the document management system, retraining staff on the new document management system, etc.) may not be justified.
Hence the course of considering the issues around having different versions on different databases. It’s certainly not the preferred option, but it may be a starter due to performance over our secure WAN. Latency to some of the more remote locations, where for example we are sometimes faced with either dial up access or satelite links, and unreliable power supply, generators, etc., may mean that the user experience of response times of 6+ seconds is the best that can be reasonably achieved over the WAN. A lot of work is being put into optimising the WAN performance, but at least in the meantime, distributed databases working client - server locally may be a key requirement.
What I would advise you is to consider an alternative for your document management solution, one that does work with the latest version. There are many 3rd party solutions for document management, and I would hate to be limited in my capability to upgrade my enterprise software as a result of an add-on. Surely migrating your docs from one solution to the next is much less intrusive, and would definately cost less, than designing a multi-version, multi-platform ERP solution that partially runs on software that has passed its lifecycle.
Hey Brandon, I agree with Daniel, going down the route of locking into an unsupported document management system sounds quite risky. You should look at alternatives to get that onto 2008.
My suggestion would be to run both SQL 2000 and 2005/2008 on the existing servers. From memory SQL 2000 will run on Windows 2K3. Upgrade all existing servers to Windows 2K3 and install two seperate instances of SQL server. You might need to throw some extra memory into the servers but probably better than having a mixed bag solution or upgrading your EDMS.
This sounds like a really exciting scenario =) However, one that is lacking “data” so to speak.
In a perfect world, where your solution is exactly as you’ve described it, a piece-meal update process to your infrastructure could take you 6 months to plan out and start executing. Once you had the hang of things the other 47 systems would probably not take much more than an additional month or so because you based all of your knowledge and scaling on the hardest system first. If you ran into bumps you could extend the program to a year for safety measures, budget based on those figures. Steps would include…
Upgrade the management system first to something that supports a higher end server & database. Update the process of using flat files to converting them to relational data that is easier to work with.
Upgrade the databases to 2005 or 2008, and finally upgrade your NAV clients & servers.
Viola. But that of course is in a perfect world…
What I am saying is that I don’t think there is enough information based on what you have described to provide you with a real good solid opinion to lead you in the right direction here. Not enough for me anyway, because I’m not going to justify all the advantages you would receive by using that new glorious software on your infrastructure. There is way too much I don’t know about how your hardware is configured, why you’re using flat file transfers, and why your document management system is being used. There just isn’t enough “Why” being displayed here for my eyes.
I think if you want good solid answers you’re going to need to tell us a little bit more about the “Why”.
Why can’t your document management system be swapped out for a better one? If it can’t run past 2000, it can’t be that great… And please don’t say “cost of training new users” that is so ridiculously minimal and I absolutely hate hearing it from people because when you REALLY think about it, its completely groundless.
Why are you guys using a de-centralized solution in the first place? There are NAP’s all around the country that are within 100 miles of any location to make this both affordable to switch to and to maintain. All those NAPs talk to each other.
Why don’t you speak with other VAR’s to see what their take on your setup is. The worst they could do with an NDA is give you a proposal for scale out change, or infrustructure re-mapping for you to consider. That will definitely plant some new ideas into your head and take some weight off your shoulders.
The more information to explain the situation that is provided, the more possibilities there are for the right answers. =) that’s all I’m saying. Nothing confidential just more to work with.