Overview:
With the release of Visual Studio 2008, Windows Server 2008, and SQL Server 2008 (in 3rd Quarter of 2008, as of time of this blog writing) I get asked if I will be utilizing the new technology or staying with the old technology. This question has some thought to be had before deciding; and for most others the thoughts can be very complex. I'm going to cover the thoughts that an everyday programmer and administrator commonly come across for a small-medium sized business. I am not covering Enterprise structures because most have some sort of a business IT roadmap/plan they will follow and require much more authorization and testing than those of smaller businesses.
Understanding the complexities involved:
First to make the best decision the IT admin/programmer will need to understand the overall objective of the business, the requirements that are expected to be met, and foremost the actual practicality of the business needs.
An example is a small sized business with less than 20 employees and probably only having 1 IT (do-it-all) person this can be a much more simple decision. This type of scenario will typically involve very few custom made applications, typically applications that can be upgraded using built-in upgrading wizards and, in most cases, will have limited compatibility problems with Operating Systems (i.e. most, if not all, systems are 1 OS version like Windows XP Professional). In this case, let's assume the IT personnel has been authorized to make the decision to upgrade on their own and financially given the 'green light'. So, what do you do? First, what OS's are being supported? In this case, Windows XP (no Vista…yet) is the prime OS. Next, how about servers being supported? They probably have 1 or 2 servers, maybe 1 server using Windows 2000 and 1 using Windows 2003; and a third server that uses Windows 2003 to backup important files on a nightly basis. Next, how many applications are custom made (i.e. using a programming language in-house, such as C# or Visual Basic)? Maybe ½ a dozen custom apps exist. Next, what programming language was used? Applications were probably developed using Visual Studio .Net (any release) with Framework 2.0.
Another example would be a medium sized business with 200+ employees, a small IT Department of maybe 10 people. Going through the same line of questions would maybe result in finding out that some employees are on Windows XP and some are on Windows Vista. You may also find out that you have more than a couple dozen custom applications and they were produced on programming languages ranging from Visual Basic 6.0 to Visual Studio .Net 2005. They might have a small server cluster with redundant clusters.
Deciding what to do:
In the first scenario, with the small business, the option is quite simple; you can choose to if you want to but don't have to because of the low amount of custom applications and no immediate worries of the OS changing. In my personal opinion I would go ahead and make the conversion to the new released software versions when possible; this will minimize the headache of upgrading at a later time when you no longer have a choice. There are two caution areas here. The first is the custom applications were developed with the intention to run on Windows XP; this can require more time to upgrade to run on Vista, but with the low amount of supported applications this can most likely be upgraded using a wizard and then revised in person over a small amount of time. The other caution is upgrading from Windows Server 2000; this one would be a strong candidate for being upgraded as soon as possible for two reasons, 1) The longer you wait the larger the leap in OS versions which means the more chance of problems, and 2) Windows Server 2000 may become unsupported during this year which will result in retrieving support via websites only and getting vital Security Updates…no more patches for bugs, and especially no more Service Packs!
In the second scenario, with the medium sized business, the option is much more difficult. First you must take into consideration is what to do with the legacy applications (referring to Visual Basic 6.0). This requires quite a large amount of conversion and will be tedious and require custom upgrading of the coding. The next consideration is the servers; how to do the migration path and to test the migration before implementation. Then comes into factor is the support aspect for the older Windows 2000 servers; with this slated to be no longer actively supported and fixes only limited to security (unless you have an agreement with Microsoft for continued patches) then this starts to become a race against the clock or a gamble each day for the security of your system (not that even using the more current versions don't have their own security gambles as is). In this scenario I would go ahead and make the switch to the latest programming language because the upgrade path is minimal for most applications made with Visual Studio .Net; and immediately find a solution to the Visual Basic 6.0 applications. I would probably at minimum upgrade the Windows Server 2000 system because the thought of minimal support from Microsoft is scary; already hard enough to get patches for the products that are fully supported, I can't imagine the problems with a product that is no longer supported in the mainstream.
What about SQL Server 2008?
This was not addressed in the above scenarios because it is pretty much the same decision process for both cases. The first question is do you want to have the latest technology, and can you risk (for the more immediate future) a new released software version. Most people have already determined to wait until Service Pack 1 is released before even testing the new technology. For the larger organizations that might already have 1 or 2 SQL Servers in production environments will most likely want to avoid upgrading those due to complexity of upgrade testing and path; and I'm the believer of if it isn't broken then don't fix it. I'd personally rather use SQL Server 2008 for newer developments, then start the migration process for the older databases as needed or opportunity presents itself. You may find one day that you have to do a complete restore (I hope you never do) and then at that point you might just decide to restore it on SQL Server 2008 instead and deal with compatibility issues at that point (this is assuming you already tested the upgrade requirements and functionality previously).
So, what do I do?
Well, it all comes down to two simple facts:
- Are you willing to put in the time to test current compatibility and perform upgrades manually where needed?
- Do you want to get the upgrade done now while you have a smaller upgrade path, as opposed to waiting another 5 years?
If you answered NO to either of these questions then stay right where you are and keep your fingers crossed that the next version of these software titles remains simple in upgrade paths. If you answered YES to either, then determine your needs and start testing before actually upgrading (there are changes and some you might not like and others you may love...try to be prepared to read/learn about the new features in all 3 products). If you answered YES to both questions, then you will want to start testing immediately and pour in your resources available to you; this will be a bumpy ride in the beginning, but will get much smoother as the dust settles and you get familiar with the new technology.
Conclusion:
Deciding whether to upgrade or not is not an easy decision to make by any means, I have only addressed two common scenarios and no one persons scenario will fit perfectly into the above scenarios. Also, these are my personal opinions and thoughts on the matter; I'm in no way a guru in this field of subject and would caution you heavily to do all the research you can and carefully plan your steps. Don't be afraid to hire a consultant if you are confused on what the best path to take is. Microsoft works very closely with many consultants and vendors in preparing them for this upgrade and handling many, many different scenarios.
In my overall opinion I feel that if you can spend the time and efforts then upgrading to the current/new technology is much better than sitting on the old technology that you feel is comfortable and works for you; before you know it you'll find that technology has just blown right by you and now you don't have an upgrade as an option and will require either rebuilding your structure or hiring someone to come in and fix everything and deal with all of the headaches (I know this, because I have been hired on with a company to fix their 10+ year old technology problems…and it really is a headache because of the drastic changes in technology architecture and methods)!
