There are two key areas that are driving organisations away from the big bang approach to Windows maintenance. One is cost and the other is risk. Businesses were finding their bottom line was being impacted every six or seven years by the cost and disruption of upgrading IT infrastructure. Many companies tried to get by or delay these costs leading to operational risk and in some cases competitive disadvantage as they struggled to keep up.
The graph below shows how companies have typically managed their IT upgrades and how they are moving to a more sustainable Evergreen approach. The effort (or cost) on the y-axis shows just how much more sustainable the Evergreen model is from a management point of view and also just how much easier it is to explain to shareholders from a financial perspective.
This article explains the fundamental differences in cost and risk between the traditional Big Bang migration and the Evergreen IT approach and then moves on to explain how Evergreen can be managed using MigrationStudio.
Big Bang Migration
Every six or seven years a company has been expected to go through a major transformation to upgrade their operational infrastructure. In terms of scope, this impacted every person, desktop, laptop, application, business unit and geographical location more or less at the same time. This was an incredible time, money and logistically intensive process.
A typical big bang migration will go through the process of assessment, optimisation and then controlled deployment.
Many of the logistical challenges of the big bang approach to Windows transformation have been solved through the use of Context, Communication, Self-Scheduling and Automation.
Context comes from widely deployed systems such as SCCM and Active Directory. Aggregating information from these tools provides the ability to drill down and see exactly what application usage looks like in for example the Finance team of the New York Office. We can determine which machines they log on to, what applications they use and how their operational environment needs to change to support the future technology.
Communication and self-scheduling empowers each and every employee throughout the transformation process, allowing them to pick a convenient time for migration that doesn't impact their business function.
Automation brings this knowledge, context and self-scheduling together to enable the delivery of that migration much faster and with a lot fewer resources.
In addition to these abilities, is a need to be able to look at an organisation from an Application centric perspective. Every department, business process, geographical location and employee is impacted by a Windows transformation because every employee relies on applications that are critical to their ability to do their job.
One of the key challenges of big bang type migrations is understanding how it effects the company's application portfolio. Each application needs to be documented to understand who uses it, how it's installed, whether it works on the new operating system, and when it can be signed off for use in the new Windows environment.
This process takes time, effort and lots of money. Is it necessary? Unfortunately yes. The stability of the entire organisation is balanced on whether applications and business processes work in the new environment.
Impact on Organisational Governance
Due to the existential threat a big bang migration will have on a company, it will rightly gain a substantial amount of attention from the CEO, CFO and CIO.
A CEO will be concerned with how this will impact the forward thinking strategy and direction of the company, the CFO on how it will impact the bottom line and future profitability of the company, and the CIO with ongoing operational management and change.
From a governance perspective, the big bang transformation strategy is incredibly time consuming and risky. It also leads to large cost spikes in the accounts that can be difficult to explain to investors and also impact cashflow on an seemingly random basis.
Evergreen IT refers to running services comprised of components that are always up to date. This is not just at the user level, but also all the underlying infrastructure, whether onsite or outsourced.
With the introduction to the concept of Evergreen IT there are a few key ideas to understand. New functionality is added to Windows 10 twice a year through Feature Updates. Security and non-security fixes are released on a monthly basis through Quality Updates. As discussed earlier, from an Enterprise perspective, it is incredibly risky to update everyone at the same time and so Microsoft has introduced the concept of Deployment Rings as part of the rollout strategy. This is a very simple concept that can be managed centrally with the use of only a small number of deployment phases.
Typical deployment lifecycle
An example of a typical deployment lifecycle would be to create the following deployment rings and rollout new versions of Windows 10 in a staged manner:
Preview: A small number of users or machines would receive early builds for evaluation to establish how new functionality can be utilised within the organisation.
Targeted: After a short preview period, a few members of each business unit receive a new major release to evaluate how it impacts their business processes, test application compatibility and sign off end user acceptance. Any issues prior to broad release can be dealt with efficiently without impacting the whole organisation.
Broad: Once the build has been signed off for general usage in each business area, it is set for broad release across the organisation. This is generally four months after a targeted release.
Critical: After an embedding period of around six months, it's time to start rolling out to critical infrastructure. All of the initial issues and concerns from the targeted build should have been ironed out by this time and a rollout to the most sensitive areas of the business can be completed.
The expectation is that application compatibility between versions of Windows 10 will be high. This means that once you have a managed application portfolio, it will only be a case of pre-testing your business critical applications before the targeted pilot phase. This amounts to a significant cost and time saving.
Impact on Organisational Governance
Unlike big bang transformations, the Evergreen IT approach leads to a much less risky or disruptive change cycle. This takes the focus away from the CEO and CFO as the rollout can be much more evenly managed, scheduled and budgeted from an annual cost perspective. From a CIO perspective they can start to release the reigns a little and allow business as usual teams to gain control and treat the transformation as they would any other business change environment.
Developing a service strategy for Windows 10 Updates with MigrationStudio
Managing the deployment
While there are a number of tools capable of managing the actual deployment of the new operating system it's very difficult to understand how the logistics of this can be achieved. It's easy to say there should be a Preview ring that lasts four weeks before a seamless transition into Targeted then Broad deployment. But how do you actually drive testing, communicate with your test users and collate all of the information, success criteria, remediate issues and then make a decision on whether to move from Targeted into Broad deployment?
There are a number of steps I would expect to go through:
- Create the Build
- Configure Deployment Rings
- Recruit volunteers
- Test the Build
- Remediate applications
- Move to the next Deployment Ring
Create the Build
This is where MigrationStudio comes into its own. The first step is to Preview the new Operating System build. Work out which features should be removed and what features could benefit the overall business strategy. At this point you can create the core build as you would expect to release it to the whole business. This would include all of your standard core apps, fonts, language packs etc.
MigrationStudio works on the concept of tracking resources such as applications, users and machines. Because of this it's very easy to additionally track operating systems, shared mailboxes, files, printers, shared drives etc. We just need to add an additional resource type.
Adding core apps to that operating system is just a matter of adding dependencies:
At this point, I can track all of the applications, font packs, languages etc against the latest operating system. Having access to all of this information via the API means that I could also easily create a build and add to SCCM as a deployment.
Create Deployment Rings
The next step is to think about the deployment Rings and how we can implement them. MigrationStudio works on the concept of Blueprints. A blueprint is a collection of resources; for example the Finance blueprint may consist of users, applications and machines from the Finance department. With that in mind, it's easy to build a Blueprint for Deployment Rings. It's even possible to break the rings down into smaller collections so I can look at either the whole of the Preview Ring or just the Finance department involvement in the Preview Ring:
The next step is to recruit some volunteers and formalise who will be responsible for testing the business applications that will be installed for each business unit. Once again, this is as simple as adding users to these specific blueprints:
In the picture above, we are adding Russell Robertson and Robert Wood to the "IT Projects Review Board" of the Preview Ring. In this way, we can set up all of our rings and define who will receive and operating system refresh and within which deployment ring.
Test the build
Depending upon the size of your organisation, the testing phase of the preview and targeted rings may be extensive. This could be a logistical nightmare as you try to reach out to each tester and get feedback on the operating system and business applications. With MigrationStudio this can be done either automatically or with a custom script:
The picture above shows the administrator running the "Create Preview Deployment Tests". This action will:
- Setup a new test case for every member of the Preview ring
- Send an email with a calendar file and optionally an RDP link to a test machine (if it's not their own desktop)
- Provide a link to each users test case so that they can sign off the build for their own business unit
Once testing has been completed and the user has fed back to MigrationStudio, it's easy to report and make a decision on whether to release the build to the next Ring, or remediate.
The picture above shows test results coming in for each Deployment Ring, who tested, when they tested and what the status is; all with one click of a button.
When and if critical business applications fail deployment testing, it's easy to raise defects, remediate the application and push back through the testing environment. This can be done on an individual application level or a complete OS re deployment, depending upon the severity of the issue.
Once all testing has completed successfully the build can be promoted to "Targeted Release" and the testing process can start again.
Microsoft's Evergreen IT view of OS deployment makes a lot of commercial sense. From a risk perspective, having a thorough communication and test strategy is imperative to a streamlined process. With the understanding that most existing applications in a Windows 10 portfolio will work on newer releases, it makes life much easier to transition the whole process from Project Management into BAU (Business as Usual).
Microsoft have created a very simple concept for OS deployment. Behind that concept is a logistical challenge. Tracking, remediation, scheduling, testing and making decisions on a companywide operating system release is complex. It would be extremely difficult to do this using Excel and Outlook. With the existing functionality of MigrationStudio combined with a toolset such as SCCM, this becomes a simple process.