 Without proper planning and execution, desktop migrations can quickly become a money pit. In part one of this series, see what you should consider when preparing a move from Windows 7 to Windows 10.
An enterprise desktop migration -- like any project -- has two major phases -- planning and execution. It's important to keep these two phases separate and deliver them in the correct sequence because of the breadth and scope of a Windows 7 to Windows 10 migration.
If this sounds pretty basic, well, it is. But like with most IT projects, the basics are frequently overlooked, and 66% of projects fail to meet their stated objectives. Keep in mind that the term desktop migration is in fact a euphemism for the full re-engineering of desktops, laptops and all related management systems. Many IT organizations do not appreciate the interdependencies of the desktop environment, so they take the overall effort for granted. Your program's plans, identified processes and desktop architecture will change as the project progresses. If you wait for absolutely final and complete solutions, then timelines will slip and costs will increase while progress all but halts. And don't lose sight of having to keep end users happy and productive while you turn their office and IT world upside down.
1. Establish a Communications and End User Education Plan
Unlike most other IT initiatives, a desktop migration project affects all users, and they need to be made aware of the migration, kept up to date on its progress, and informed about when they will be affected and how their data will be moved.
While desktops are a corporate asset, many users have a personal connection -- as well as a fair amount of individual data -- on their machines. Employees need to know how to deal with the data that exists outside the supported programs. Furthermore, because the move from Office 2003 or 2007 to Office 2010 or 2013 includes a completely new interface, it's important to train end users on how to access it in order to reduce productivity loss. In addition, IT needs training on new features, capabilities and programming standards.
Remember that people of different generations learn differently, so offer training that fits everyone's needs. Developing these training programs takes time, and it needs to be made available just as people are migrated. If you offer trainings too early, your users won't remember the content. Offer it too late, and your users will be frustrated and unproductive, and they will likely view the overall migration unfavorably.
Application-development planning needs to start as soon as possible. Developers need to review their apps and determine the level of impact and cost on their parts of the portfolio. There are significant differences between commercial, off-the-shelf applications and those written internally, and time needs to be set aside to address problems that could arise.
2. Architect a single 64-bit Desktop and Laptop Image
Design and build a base desktop image where additional components can be added as they are made available for Windows 10 and the new platform.
If you do this as quickly as possible, early adopters and application developers can start testing the environment and become familiar with the changes to the operating system and Office 2010. Evolve the build with regularly scheduled updates and enhancements. These updates should include vetted common components such as middleware and other third-party applications, as well as changes based on newly-collected information.
Furthermore, you can incorporate developer and early adopter experiences not only in the next scheduled desktop image release, but also in business communications about the program. Create a schedule of image releases to roll out changes and fixes regularly (but not so frequently as to be disruptive). Quarterly releases are more than sufficient.
Use this project to get to a single common desktop image with add-ons for specific business divisions or user communities. Managing multiple images will just increase the project cost and duration because each one will require its own packaging and testing activities.
As for the 32- or 64-bit decision, go with 64-bit. Gartner forecasts that that by 2014, more than 75% of PCs deployed will be 64-bit, and including this as part of the overall project could reduce costs. You won't get a performance boost from the move, but you are future-proofing your environment. New devices and commercial off-the-shelf software are being developed for 64-bit machines, and organizations need to be ready. Plus, moving to 64-bit does not make an overall Windows 10 migration any more difficult. If every application has to be tested for Windows 10, test it for 64-bit compatibility as well. The most significant potential problems are firmware and driver incompatibility (64-bit drivers must be used) and how to support older equipment for which drivers don't exist and the manufacturer has no plans to offer them. Once the hardware architectural decisions are made, start the vendor selection process and put potential desktop equipment out for bids.
3. Define an Unambiguous Migration Process
All the extended team members, including the application developers, the packaging team and the testing team, must understand what they're expected to do and when they need to do it. The verifiable outcomes for each phase must be defined so that the end of one step and the beginning of another can be clearly tracked and measured. Accountability will help the program achieve major milestones.
Create an overall process description, but provide enough details so that any program outsiders will be able to do what they are asked to do. Developers who deliver ahead of the project plan (a very good situation) can quickly become thought leaders and help tune and improve the process for the rest of the team. They can just as easily slow the project down by informally sharing their unsatisfactory experiences based on a lack of guidance from the core program team. Get the process guide distributed as part of the communications plan as early as possible. The migration process needs to address the complexities of end-user data storage, variances from company standards and disparate configurations across the enterprise. Include steps to verify client data locations, save the existing user desktop state and specify which data will be migrated. Consider setting a policy where nonstandard data storage migration is the data owner's responsibility.
Starting a major project without a stated direction leads to confusion and disillusionment within the team and ruins the credibility of the program leadership.
Certainly, early in the project lifecycle, there are many unknowns. As the migration progresses, you can apply the lessons learned and update the process. The program team can't anticipate everything, and that's OK. But there must be a concise and defined way to modify and communicate changes to process.
4. Create a detailed and Achievable Project Plan
Since enterprise migrations typically touch every company employee, they are by nature very visible. Everyone will see delays. Preventing -- or at least reducing -- these delays requires basic project management skills. Create a plan, manage it, and hold people accountable to delivering accordingly.
The plan should be detailed enough so that delays can be addressed quickly and the problems fixed. It must also be developed from bottom up. This means you need to determine the major milestones and final cutover date based on the sum duration of the tasks. For a program this large and complex, do not pick the timelines based on the personal preferences of executives. This will result in missed deadlines and an overall poor program quality.
The migration effort is similar across organizations. Enterprises are basically the same when measured by end-user populations, the number of applications and office documents, and support staffs. This leads to similar levels of effort and timelines, regardless of company size. It's going to be a chalenge, but not insumountable.
5. Build an Effective, Cost-efficient Team
Thankfully, enterprise migrations don't take place on a regular basis. As a result, however, most organizations don't have deep upgrade, migration and conversation expertise. They also don't usually have robust testing environments and capabilities. On top of this, with all the recent cost-cutting, many staffs already work long hours.
Determine early on which capabilities and skills are needed for the migration. It's best to pull this information from the comprehensive project plan.
Take advantage of the people who do migrations, conversions, packaging and testing for a living. Application-specific knowledge and corporate engineers and architects should almost always be internal, but most of the other team members can be sourced from third parties. A migration project requires a specific skill set, so there is no reason to build capabilities that will expire at the end of it. Talk to software and OS vendors who are familiar with their products' problems. Offshore companies can provide conversion, packaging and testing services. You should also look for professional services firms that can be your single point of contact for the whole initiative.
In addition to identifying the resources available, look at the expected manual processes and see if there are any tools that could do the work more efficiently. Some fairly mature tools address applications as well as Office content. These tools can help you identify how big your problem is and populate your inventory databases. They can also be used to create "RAG" (red/amber/green) impact ratings and, in the case of "amber" problems, fix them. Investigate which tools are appropriate, get and install them, and then put them to use.
|
Technology Project Management
Website Design and Development
Custom Development Conversions
Advanced Technology Consulting
Vendor and Supplier Management
Cloud Based Video Conferencing
Customized On Site Training