On the surface it looks simple. Your business runs 25% of old servers. They are no longer supported.
You need to remove them. You have choices regarding what to do with legacy services - which boils down to decommission or migrate to something new.
That 25% of servers could be a few hundred or a few thousand Windows servers.
When the project team puts together they start forecasting, based on a rudimentary "metric" (say, three
server types a week - that is three different roles, not three actual servers). And the plan pans out,
clearly showing progress and eating into the company IT budget. Funding that could be used on business differentiators.
A few weeks later the schedule starts to change. Because you've hit what we call the cats-cradle of a windows server migration. From an initial discovery and assessment it will be obvious the servers each provide a role and handle data in some way. It is also logical to determine the dependencies between services and therefore the associated services. But then it gets deeper and as you make an attempt to
make one move it has a ripple effect somewhere else in the environment which means more stakeholder meetings and more agreements as to how to ensure old promises and future needs are met.
Single Server Example
For instance, operations manage and operate the Windows servers. Therefore there is a maintenance
contract, data, archiving and backups to be considered. It might be possible that the old servers are
not backed-up with the same solution as newer servers in the environment. So it seems "easy" - just
migrate live data to new data storage and backup and archive unwanted data.
But then you realise the current and future backup system will not be able to read the old tapes. So then measures need be made to get the data to the new backup system in order to archive it. What seemed quite a simple act, getting some data to tape, is in fact a logistical challenge. Before the Windows server is shutdown you will need to ensure the application is moved, data is backed-up, monitoring systems are reconfigured and the new platform can both monitor and provide data backup and archive services. No mean feat.
And that's just for a single server.
Multiply this by a a few hundred servers and a hundred Line of Business apps and you are facing a
lifetime of change.
even more frought to cause and effect and to the point where you will ceast to be able to make a change.
Therefore it is important to keep things simple throughout a Windows Server 2003 elimination project.To take time to think and look at things clearly. Some recommendations that might help deliver a Windows Server 2003 remediation are:
- Dedicate project resource. Navigating inter-dependencies and getting buy-in from stakeholders takes time.
- Keep an up-to-date inventory of servers
- Keep an up-to-date inventory of applications
- Treat each server as a mini-project in itself, with its own beginning, middle and end
- Keep track of the lessons learnt
- Keep track of the promises made as part of the decomissioning stage
You need to be a Zen Server Migration lead. You need to ensure, where possible, that each server workload does not get too complex.
And lastly, you need to deliver.