Now
that the prototype phase has been completed, the deployment team will
be raring to go and have hands-on experience with all the new
technologies to be implemented. The process documented in the migration
document and migration plan will have been tested in the lab environment
as completely as practical, and documentation detailing the steps to be
followed during the pilot implementation will be at hand.
Although the pilot process
will vary in complexity based on the extent of the changes to be made
to the network infrastructure, the process should be well documented at
this point.
It is important to identify
the first group of users who will be moved to the new Windows Server
2008 R2 environment. Users with a higher tolerance for pain are a better
choice than the key stakeholders, for the most part.
Note
In many organizations, the
CEO, CIO, VP of sales, or other key executives might want to be part of
the initial pilot rollout; however, we suggest not making these
individuals part of the initial rollout. These individuals typically
have the most complex user configuration with the lowest tolerance for
interruption of network services. Users in the production environment
with simpler needs can be used for the initial pilot. If necessary,
create a prepilot phase so that the senior executives can be part of the
official pilot phase, but don’t make the challenges of pilot testing
more difficult by starting with users who have the most complex needs.
A rollback strategy should be clarified, just in case.
Test the disaster recovery and
redundancy capabilities thoroughly at this point with live data but a
small user group to make sure everything works as advertised.
Migration processes can be fine-tuned during this process, and time estimates can be nailed down.
The First Server in the Pilot
The pilot phase is begun when
the first Windows Server 2008 R2 server accessed by users is implemented
in the production environment. Dependent on the scope of the migration
project, this first server might be a simple application server running
Terminal Services or Windows SharePoint Services, or the first server
might be an Active Directory domain controller.
Just as in the
prototype phase, the testing to be conducted in the pilot phase is to
verify successful access to the server or application services the
system provides. One of the best ways to validate functionality is to
take the test sequences used in the prototype phase and repeat the test
steps in the pilot production environment.
The major difference
between the prototype and pilot phases is interconnectivity and
enterprisewide compatibility. In many lab-based prototype phases, the
testing is isolated to clean system configurations or homogeneous system
configurations; however, in a pilot production environment, the new
technology is integrated with old technology. It is the validation that
the new setup works with existing users, servers, and systems, and
software that is the added focus of the production pilot phase.
Rolling Out the Pilot Phase
The pilot phase is usually
rolled out in subphases, with each subphase growing in number of users
affected, uses of system technology by the pilot users, and the
distribution of users throughout the organization.
Quantity of Pilot Users
The whole purpose of the pilot
phase is to slowly roll out users throughout the organization to
validate that prototype and test assumptions were accurate and that they
can be successful in the production environment. An initial group of 5
to 10 pilot users (typically members of the IT department overseeing and
managing the migration) are first to be migrated. These users test
basic functionality.
After successful basic
testing, the pilot users group can grow to 1%, then to 3%, on to 5%, and
finally to 10% of the user base in the organization. This phased
rollout will help the migration team test compatibility, connectivity,
and communications with existing systems, while working with a
manageable group of users that won’t overwhelm the help desk services in
place during the pilot and migration process.
The pilot phase is also a time
when help desk and migration support personnel build the knowledge base
of problems that occur during the migration process so that if or when problems
occur again (possibly in the full rollout phase of the product),
lessons have been learned and workarounds already created to resolve
stumbling blocks.
Application Complexity of Pilot Users
In addition to expanding
the scope of the pilot phase by sheer quantity, selecting users who have
different application usage requirements can provide a level of
complexity across software platforms. Application compatibility and
operation are critical to the end-user experience during the migration
process. Often, users won’t mind if something runs a little slower
during the migration process or that a new process takes a while to
learn; however, users will get upset if the applications they require
and depend on each day to get their job done lock up while they use the
application, data is lost due to system instability, or the application
just won’t work. So testing applications is critical in the early pilot
phase of the project.
Role Complexity of Pilot Users
Pilot users should also be
drawn from various roles throughout an organization. In many
migrations, all pilot users are tested from a single department using
just a single set of applications, and it isn’t until the full migration
process that a feature or function that is critical to everyone in the
organization (except the pilot group users’ department) doesn’t work. An
example might be a specific financial trading application, a
proprietary health-care tracking application, or a critical sales force
automation remote access tool that causes the entire project to come to a
halt far into the full rollout phase.
Geographical Diversity of Pilot Users
The pilot group
should eventually include members geographically distributed throughout
the organization. It is important to start the pilot phase with a set of
users who are local to the IT or help desk operation so that initial
pilot support can be done in person or directly with the initial pilot
group. Before the pilot is considered complete, however, users from
remote sites should be tested to ensure their user experience to the new
networking environment hasn’t been negatively affected.
Fixing Problems in the Pilot Phase
No matter how much
planning and testing are conducted in the earlier phases of the project,
problems always crop up in the pilot phase of the project. It is
important to have the prototype lab still intact so that any outstanding
problems can be re-created in the lab, tested, and resolved to be
tested in the pilot production phase again.
Documenting the Results of the Pilot
After the pilot, it is
important to document the results. Even with the extensive discovery and
design work, as well as the prototype lab testing and pilot phases that
have taken place, problems might reoccur in the postpilot phases, and
any documented information on how problems were resolved or
configurations made to resolve problems in the pilot phase
will help simplify the resolution in future phases. If you take some
extra time to give attention to the pilot users, you can fine-tune the
solution to make sure the full implementation is a success.
