We have posted a lot of text-heavy posts on this blog regarding Windows Server 2003 End of Life. Before we move onto the next stage - what platforms to migrate to, we thought it worth sharing some of the related videos:
I run a business that profits from this need to migrate from 2003 Server but it is still worth exploring other avenues...
For those that need to remove 2003 - fine, you know your direction.
For some other companies we meet their server teams are confident they do not need to rush to eliminate the legacy OS, based on other safeguards, data and usage.
Issue: Deciding whether or not to tackle those Windows Server 2003 machines is not a black and white scenario.
A bit of a headache, especially if the remediation work will affect service and necessitate expense on redevelopment. In many situations solutions like AppZero are the answer, virutalise and move the problem without having to revisit the code.
We've also made the point that from a technical and delivery point of view these same problems present very interesting and highly challenging work. Trying to dismantle and build systems and introduce new solutions simultaneously across tens or hundreds of workloads is no mean feat.
Windows Server 2003 EOL cannot be treated like XP EOL nor can Mainframes be used as a good reference point (any malware developers out there with a IBM mainframe at home?).
When undertaking your Windows 2003 End of Life decommissioning process it’s the old rule of 90% preparation and 10% migration effort. One of the more lengthy investigations we’ve found is determining application usage. You will likely discover multiple applications that your client relies on and some of them could be many years out of date.
Determining the users of these applications can be tricky, as there are potentially multiple ways to do so:-
- Interview the app owner / end-users
- Use Asset / System Management toolsets and query the data.
Windows 2003 EOL - Data Migration Challenge
One of the major hurdles we've faced when performing migrations of client systems and services to supported platforms as part of a Windows Server 2003 EOL exercise is remembering all of the utilities and tools that were available at the time. Some of these tools were ported to new platforms, some have been retired.
As technologies move on and we become used to closer integration and interoperability, you might find yourself over complicating the situation!
Something I've seen many times in business is the lack of visibility of IT infrastructure. Regardless if it is within corporations or small business this is generally down to the same reasons: - the IT infrastructure grows organically over time and we become too busy dealing with business issues to start thinking about setting up an inventory.
I admit building an asset inventory may appear not to be important when there are more pressing matters to deal with.
For some organisations, setting-up an asset register via SharePoint or intranet has been attempted and the service desk tool, whilst it collects all the information we need, is quite cumbersome to get the necessary information. Often there's a Microsoft Access database that has been created that has evolved into its own Line of Business application.
We've established that a Windows server migration and elimination project is a bigger challenge than a "single" technology product implementation (single is in quotes as no system is implemented in isolation). We've also recommended tracking Windows Server EOL project progress from both a server and application level in order to manage the project and keep stakeholders informed at the appropriate level.
Once a Windows Server EOL / migration project commences the pace can become quite frantic as you need to fully understand and discover your environment (even if it is an environment you know intimately).
As part of this discovery your team often need snippets of information to be able to assess what is really happening across your infrastructure and determine inter-dependencies between services and servers.
A common scenario we have encountered during a Windows Server Migration project is re-visiting technological change and challenges that we part of a merger or divestment that occurred many years previously.
During the original merger project deadlines were tight and resources were limited so the most pragmatic approach was made. Something like connecting the two businesses via the company WAN, placing an Active Directory trust between the two businesses, possibly absorbing the Exchange mailboxes and then letting both companies operate as two distinct entities.
Other than cost and time one significant factor for this approach is because the analysis of the similar systems and integration would be very time consuming, difficult and costly. The benefit of this approach was time and the ability to keep strict lines of administrative control and data boundaries where needed.
In the first two articles in this series we covered some general considerations when upgrading Windows Server 2003 in-place to Windows 2008 and some specific requirements when upgrading to a VM hosted on Hyper-V.
Upgrading an Operating System is no small task, just think about all the processes that have to occur in order for the setup software to successfully update to a newer version. This is why we shouldn’t be too hard on the pre-installation setup checks as its impossible to get it 100% correct.
It is likely you will need to manage a number of Line of Business ("LOB") applications as part of a Windows Server 2003 End of Life programme. When thinking through a Windows Server migration (or decommission) you will need to discover and remediate business applications.
Unlike a new technology programme, a Windows Server 2003 EOL (WS2003EOL) project is likely to be seen as not implementing anything "new". This means that the resources are often not seen as architects - they are more demolition men and therefore not seen in the same light. Job titles might be "Server Engineer" or "Server Migration Lead". But there are elements of "design", simply because you need to find a new home for the old services.
As part of our overall series on Windows Server 2003 End of Life, this blog post outlines some of the steps you might take when migrating a single application. There are application virtualistion solutions available which can help avoid some of these steps but you will not eliminate interaction with the end-users, customers and stakeholders - areas that will take most of your time.
Many Windows 2003 servers have already been P2V’d as IT departments strive for greater consolidation of their assets, greener credentials and removal of asset based risk (aging hardware etc).
Therefore you are likely to be dealing with Virtual Machines and as discussed on Part 1 – this make life significantly easier when performing upgrades to Windows 2008.