And other stories in this blog...
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.
When implementing something new, we tend to "layer" it onto the existing infrastructure and integrate it with existing systems. We could take Exchange Server, as a "simple" example. You are tasked to upgrade to the latest and greatest version, matching business requirements to new features and ensuring old features/functionality still operate as expected. Installing the product is relatively easy but testing against business need and working with all stakeholders takes time and effort.
In an ideal world, once the new technology is in place, you decommission the system that is being replaced. Taking a well-known product, say Exchange, the project team do some form of R&D, PoC and implementation. It is "just" one more product to be implemented and the team is dedicated and focused on the work stream. And that's the main difference - the focus.
Differences during a Windows Server EOL Project
In contrast with a Windows server decommission project it is akin to a game of Jenga or Kerplunk. All the servers and systems are stacked-up upon each other, so you have to carefully plan your move. In addition you are tasked with multiple (20+) technologies and multiple (say, 100-1,000) Windows servers.
A Windows Server 2003 elimination programme consists of one large work stream with each server itself representing a work stream that needs to be managed.The focus is very different as you need to time- slice your attention to each sub-task within the project.
With a Windows Server Decommission project you may be working with 30-40 workloads, representing hundreds of servers. Each workload has an management overhead as you design, propose and implement change. Including, but not limited to, systems architecture and change management. If we compare with
our Exchange Server example,it seems very simple - there is a single focus (Exchange) and the related integration and stakeholders.
What's more, if you have an issue implementing Exchange you can refer to a multitude of material - websites, blogs, Microsoft MVA, other Microsoft Exchange experts, Microsoft Partners, Microsoft
consulting and Microsoft support. But for a Windows server decommission project this is not the case,because the job is effectively dismantling and migrating - within a unique combination of applications and data and dependencies. Hence there is very little material you can rely on.
Often you must rely on team members with legacy knowledge to ensure success, be it scripting languages (Kixx etc) or referring back to 'old ways of working'. Older technologies are nothing like as intuitive as their modern counterparts.
Therefore it is essential to set some guiding principles for the project and develop a workflow that can be run against all servers in order to assess them "fairly". This will also help estimate time and resources required.:
We've already highlighted the complexities of a Windows Server 2003 EOL project but when comparing against a team that only has to implement a single new technology it becomes ovbious an 2003 EOL project requires work across many systems and working with many people within an Enterprise.
Being allowed to inspect a business operation and decommission and replace their Windows Server systems is quite an honour as you the team are trusted to make the right change for the company and employees as a whole. Once you have assessed the internal systems you need to propose cost-effective change.
Usually these assets have been written off - so Enterprises are seeking a cost effective method of asset disposal in addition to the security concerns.
The above considered...it is no mean feat to remove those legacy servers.