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.
One of the useful side effects of Windows 2003 decommissions is to take the opportunity to consolidate your physical footprint by virtualising your estate further. There are many advantages to this as described in here.
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!
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.
This blog post is part of an overall series on Windows Server 2003 End of Life activity although it can be applied to any server decommissioning project. The aim of this post is to compare a new technology project versus a Windows Server decommission project. in order to highlight what expect when embarking on a Windows Server decommission programme.
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.