Windows 10 is likely to be the fastest adopted operating system in modern times if the first two months of statistics are to be believed.
Of course, most of the data in this initial wave is from the consumer market, but as we know, fast consumer adoption often drives faster enterprise adoption. After all, no one wants to be running an operating system at work that's significantly slower and older than the one they run at home.
Additionally, Microsoft's emphasis on the ease of an upgrade to Windows 10 has led to peaked interest amongst the enterprise market. Microsoft has high expectations for widespread enterprise adoption by 2018.
As a result, many organizations are already investigating and budgeting for their Windows 10 upgrade. Similar to previous updates, there are many considerations to be had before large-scale deployment can commence.
Given that we have successfully readied over 5 million assets for desktop migration by Juriba software, we thought we would summarize our experience of the essential components required to plan for a successful enterprise Windows 10 migration project in 11 easy-to-follow steps:
- Plan For The Plan
- Plan & Build Your Project Scope
- Plan Your Internal and Extended Project Team & Structure
- Plan Your Target Infrastructure & Platforms
- Plan How You Will Design, Build, Test & Manage Your Gold Operating System Image
- Plan How You Will Rationalize Your Application Estate
- Plan Your T(minus) Timeline
- Plan Your Scheduling Methodology
- Agree Your End-User Engagement Plans
- Plan Which Software Tools Will Best Support Your Migration Efforts
- Plan Your Deployment Logistics
So without further ado, here we go:
1. Plan For The Plan
This might seem like a very odd place to start, but it is amazing how many IT projects do not allow time to plan to build the plan.
I remember the first time I heard this term "Plan for the Plan." A bunch of bewildered faces were looking at the program manager who had uttered the words. She said, that while her job was to build the plan, where she needed to start was a plan to develop the plan.
It is a common misconception that large scale projects start on Day 1. They do not. A project can only really start when everyone involved understands the program objectives, their role within the project, and whom they need to interact with to get their job done.
Good examples would include stakeholder discussions:
- What are they expecting out of the project and have the objectives been agreed?
- What should the major milestones be?
- How should we engage with the relevant delivery teams and what objectives will they need?
- What should the schedule look like?
- How do we identify the risks to the project?
Ultimately, the first deliverable of any IT project manager worth their salt should be a project plan with a start date and an end date that is agreed by all parties. By having a plan for the plan, you will create time to build something that identifies the key objectives and get the appropriate buy-in before you commence with the real plan. The plan for the plan can often be as important a document as the plan itself – something to refer back to when things change on you and outlining what you need in terms of resource time and decisions to build a realistic project.
2. Plan & Build Your Project Scope
When setting out any IT migration journey, it is crucial (and a huge cliché) that you know your destination. This means understanding the entire end state for your Windows 10 users, from the infrastructure that supports them, the deployment tools used to provision them and the request / problem ticket systems that will service them.
Your migration will touch most element of the IT services you provide to your end users, so like a jigsaw, you need to look at the big picture, not just the technical ‘how to’.
Whether your project is “boiling the ocean” and making big changes, or just upgrading like for like, agreeing the scope and outcome of the project should be your number one priority. This project, as much as any other, is an excellent opportunity to change and fix things in your end-user space. Equally, it is the most likely project to be subject to scope creep. Without clearly defined boundaries, it is possible that your budget, time and resource to deliver could get blown in just a few weeks of ‘if you could just’!
Ensure that your scope and deliverables are SMART (Specific, Measurable, Achievable, Realistic & Time-Bound) and that your budget, timeline and resource plan enable you to deliver exactly what you said you would in your business case.
3. Plan Your Internal and Extended Project Team & Structure
Having worked with hundreds of IT migration experts across multiple projects, we can safely say that one of the most important elements of any project is having the right people and skills to deliver it.
In conjunction, building the proper project structure, governance roles and responsibility to manage it, is equally important. Of course, depending on the size of your project, your team could be as small a couple of individuals, or as large as a global team numbering into the hundreds. The challenge is to make this team as efficient as possible while ensuring that all the moving parts are coordinated and busy delivering the target state.
When building your team, you need to think about the different skill sets you will require. Project managers, technical project managers, program officers, process experts, build engineers, infrastructure experts, business liaison officers, communications experts, risk managers, logistics coordinators, schedulers, deployment engineers, software developers, application administrators, application discoverers, application packagers and user acceptance testers are just some of the multitude of individuals that may be required to deliver your project.
Think also about the skills that you might not have in-house. Do you have the bandwidth to run the project internally? Do you need to supplement resource? Do you engage a third party for your hardware logistics? It is likely that to deliver your project, you will include a mixture of internal and external resources.
Thinking about how you will structure this project team, defining roles and responsibilities and setting appropriate goals will provide a great framework to start your project.
4. Plan Your Target Infrastructure & Platforms
Successful desktop migration projects have one element in common: a well-designed and architected platform from which to deliver your operating system, your applications, and your end user computing environment.
It is likely that your target infrastructure will be a hybrid mix of fat and thin client, virtual machines, mobile devices and potentially an associated enterprise application store. Calculating your target numbers for each user or migration type, and sizing your infrastructure accordingly will give you the flexibility to manage changing requirements during the project.
Likewise, a review of your existing desktop management infrastructure, deployment technologies and supporting systems is likely to highlight the need for update and upgrade. Many organizations will use Windows 10 as the opportunity to migrate or upgrade to SCCM 2012, implement an end user application store, improve on asset management processes and get the environment into a healthy state. Planning for this additional work and building in the dependencies for your project plan will help to ensure that you set realistic targets from the outset.
Getting your architecture right and testing your multiple deployment use cases will be critical to the ease of migration, and the success of the operating environment once your users have transitioned.
5. Plan How You Will Design, Build, Test & Manage Your Gold Operating System Image
Too often desktop projects spend more time than originally budgeted for on getting their gold build ready and tested. By the time it is finally released, it is already a huge number of patches and hotfixes out of date, and the constant change means an elongated OS deployment time for your deployment engineers.
Successful projects have a clear vision of what is included in the gold build, and how it will interact with the end state user environment.
If you do not have one in place, you should decide on a technology to manage your build image. It will make it much easier to make amendments as you prepare for your rollout and as you need to append to it throughout the deployment.
Ensuring that your requirements are well specified from the outset, and building your image with the drivers, configuration, security products and settings, applications, policy and profile settings that you need will help to achieve a more supportable golden build image.
Also, ensure that you fully test the image and all of its configuration against the back end infrastructure whether it is a virtual machine, a laptop, a desktop, thin client, or mobile device.
6. Plan How You Will Rationalize Your Application Estate
Many projects flounder at the outset with the size of the application estate, and how to categorize and rationalize it.
With Windows 10 employing the new Edge browser, checking and testing web applications will be equally as important as testing your fat client applications. If you packaged your applications in MSI or AppV format for Windows 7, then these should most likely be ready for Windows 10.
Application management in IT migration is worthy of its own blog post, but here are some of the questions you should ask in your planning phase:
- Where is my application inventory stored?
- How will I identify the applications that the project does not care about?
- How will I identify my business applications?
- How will I categorize applications for rationalization?
- Will I determine application usage to decide applications to take forward?
- How will I determine application licensing status?
- How will I determine target state application packaging/delivery platform (local/MSI/AppV)?
- Where can I establish application compatibility with the target OS and gold build?
- How do I determine my application owners?
- What will be my application testing and signoff process?
- Where will I hold and update my master and rationalized applications lists?
- How will I perform business user acceptance testing?
- How will I track application packaging workflow and readiness to migrate?
- How will I refresh my application data into the project?
- How will I manage the deployment of applications to my users?
If you can answer all of the above questions, then you are a significant portion of the way towards generating a plan to handle your applications. Generating the tools, processes and procedures to support your application management will take time, but if you plan correctly, you will give yourself a much better chance of taking your current application estate and get to your target state in a much faster time.
7. Plan Your T(minus) Timeline
Many projects fail to appreciate the myriad of dependencies, processes and procedures required to support a project of this size and complexity.
Consequently, more resources are needed to run manually pieces of the process because they have not been standardized appropriately. For example, understanding for each piece of refresh hardware how long the approval system takes, how long it takes from order to ship, and how that new kit is tracked to the organisation and mapped to the legacy device will all impact the possible T- timeline.
Therefore, it is strongly recommended that the project plans up front how long the T- process should run, what criteria needs to be met before an asset can enter the process, the process steps and when they happen (these have to be split out by migration type since a rebuild may have an accelerated timeline compared to a replacement).
The timeline should include every aspect of the migration pre-amble, scheduling and deployment, and be documented in a format that should enable you to identify which tasks can be automated further down the line. The clearer that you can define your schedule of activities, the greater your chance of running a successful end to end migration process.
8. Plan Your Scheduling Methodology
How migration scheduling is going to happen in your project (e.g., the roles and responsibilities of the project team, as opposed to the business liaison officers) is an often overlooked element of migration planning.
- Who is going to build the deployment schedule?
- What drives the schedule (user readiness, application readiness, building readiness, department readiness)?
- Who handles changes to that schedule?
- How are deployment capacity constraints defined?
- How will any third parties input to, and consume information from the schedule?
- What change control will be required to manage the schedule (e.g. is there a lock down period)?
- Are there any business or company blackout dates that impact the schedule?
- How will the project team and business liaison officers communicate the schedule?
All of these and more should be assessed and discussed within your planning efforts. Scheduling is an area that can become extremely complicated if it is not planned correctly at the outset. Of course, we also recommend that you employ a centralized tool to manage the schedule. Passing spreadsheets around will just add cost, add resource and increase complexity for what should be a relatively simple logistics task.
9. Agree Your End-User Engagement Plans
One common attribute of successful IT transformation projects is that they have a good plan for how they are going to manage end user communications and other required interactions.
In its simplest form, this might purely relate to whether or not the end users are going to be receiving e-mails about their migration, and if so, how many.
In the more complex projects, it could be a set of emails, tailored to their migration path, supporting multiple languages that get triggered on a specific set of events. Planning the how, when and why of end user email communications will help to speed the implementation when the time comes.
Additionally, we are now much more likely to want to engage our end users through multiple means. In many cases, this could mean including facilities such as a self-service portal to gather or validate data from the end users directly. Even more sophisticated, it could mean a self-service scheduling service that enables the users to choose their own more appropriate migration date.
Understanding the number and frequency of communications to both your business liaison officers and the end users will help accelerate your project processes and improve the end user perception of the project if you get it right.
10. Plan Which Software Tools Will Best Support Your Migration Efforts
With so many IT migrations to manage, it is no surprise that supporting software tools have come to the market in a big way.
Your organization will probably already be using some for user directories, software and hardware management, application workflow management, request and problem ticket systems.
These are great business-as-usual tools and can provide excellent sources of project data. However, a well-managed project will also consider the following:
- Do I need to discover hardware/software inventory and application usage?
- Where will my data warehouse be, and how will I refresh the data periodically?
- How will my project team communicate and collaborate?
- Where will my master applications list and rationalized applications list live?
- How will I track the packaging status for my applications?
- How will I test for application compatibility?
- Do I need end user acceptance testing, and if so, how will I perform and track it?
- How will I communicate to my end users and do I want to automate this?
- Do I want to automate/trigger deployment?
- How will I manage my user profiles?
- How will I track my vendor orders and logistics?
Undoubtedly, software tools can significantly accelerate your migration efforts.
However, like all software implementations, they should be planned correctly from the outset. Ensuring that you understand how they will integrate with your internal processes and tools should be established from the beginning.
Likewise, having appropriate expertise or time to learn and build them properly must be factored into your plans if you are to get the best out of them. Too many projects look to bring in software tools without the requisite efforts or strategy to integrate them. Consequently, the project does not work as efficiently as it could have.
11. Plan Your Deployment Logistics
Our final section involves the most often overlooked item that is planning the ‘how’ of your deployment logistics. It is amazing how many projects will set off with a scope that is physically not achievable.
For example, can you order the specific piece of standard kit for all of your offices globally? What capacity can your teams physically deliver in a given timeframe? Can your ordering process support the required volume of orders and approvals required? How much time is needed between order and delivery, and does it change per country?
The third party vendors are as guilty as anyone of over-simplifying this complex area. Their service is to make the logistics none of your concern, but the reality is that their service is part of your project and has to be planned in the same meticulous detail as all other areas.
Understanding ‘how’ you are going to interact, and agreeing your service terms in the context of your project goals is an activity that should be started in the planning phase.
It is a great concept to think that suppliers can just throw people into a project at a moments notice, but that is not often a reality. Suppliers can only offer benefits like fixed price deployment if they can guarantee volumes and timeframes which enables them to build their resource plan and ultimately make money. No supplier wants to be left with resources on-site that are not at full capacity. If you are running the project internally, under-utilised resources are a budget killer.
Want to download this article as a PDF?
No problem. Simply fill out the form below and you will be able to download the PDF version of the article right away.