IT spending has had a huge impact on many businesses over the last five years. The exodus from XP to Windows 7 was painful, slow and expensive. Many companies weren’t prepared for such a massive change. XP was like a colleague who’d worked alongside the business for over a decade, productively working away without too many issues. Then came the time to upgrade; technology was changing at a rapid pace. New processors, connectivity, tablets and better battery life would provide a more mobile workforce with better efficiency. Security became a major concern with numerous stories in the press of leaking information with viruses, trojans and rootkits becoming the word of the day. XP couldn’t cope and it was time to move on.

As the desktop migration gathered pace Microsoft released Windows Server 2008, then Server 2012. With the focus and main spending clearly on the user experience, the servers were left behind. They just worked, almost 24-7, no real problems to report. The back end business chugged away as it always did. Then came the hacker collective: Anonymous, Global Warming, massive mergers and acquisitions and then a sudden realization that disaster recovery plans just weren’t good enough. Once again it was time to move on.

Unfortunately, just like the desktop migrations, there was no information as to how these servers were built, how the applications were installed, who used them or what the external dependencies were. What would happen if these servers went off line? What would be the business impact? Who would be affected? Nobody knew. With no solid information, facing huge risk and no real financial gain, most businesses did what most businesses would do: They pulled the duvet over their eyes and said “Just five more minutes”.

As Microsoft finally pulled the plug on Windows Server 2003 support in 2015 the panic was on. Punitive maintenance costs, major security concerns and a realization that businesses really had to become more efficient to survive. With a quick hospital pass back to the CTO the business has finally started to move. Windows Server 2003 must go.

Similar to a desktop migration, each server has its own users, applications, dependencies. Additionally, there is a huge amount of documentation to discover, plans to go through, disaster recovery mitigation, change control, issue remediation, installation instructions and finally a migration day run-book to ensure everything goes smoothly.

From early on, we realised that AppTracker could track anything. It was great for managing application workflow as well as user and potentially machine migrations.

With the development of the machine migration side we realised that we could start to properly focus on server migration as well. There is a different methodology with server migrations and a lot more external dependencies, components and tasks to deal with that need to come together to co-ordinate the whole migration.

With this in mind we changed the focus of modelling server applications to a Projects, Components, Tasks and Servers view.

This means that we can now use AppTracker’s meta data defined knowledgebase, comprehensive API, dynamic reporting and communication capabilities to manage server migrations.

As a simple example, let’s look at moving an AppTracker server:

In this case you can see we have used two servers: WEBSRV01 for the web server and SQL01 for the AppTracker database. We’ve assigned some very basic tasks and wrapped it all up as a project called AppTracker.

We can look at all of our projects on one screen and see when they are due to be completed:

We can also see a breakdown for each task:

We can manage the build process of each of the servers:

Schedule activities for each component on migration day:

Work out project readiness and report on a live interactive dashboard: