Migration

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Allen Jones

Chapter 3 from Windows Client Administration, published by Sybex Inc.

In this chapter, I will discuss the three major categories of migrations:

• Desktops and Operating Systems

• Applications

• Hardware

While perfection is always the goal, rare is the case where a migration will go smoothly and without a hitch. You can minimize migration headaches with good planning as described in Chapter 1. This chapter will also provide several example cases of migrations and how they might affect the fictitious Internet Calendar Company.

On This Page

Successful Migrations to Windows Clients
WinClients@Work: Sample Migration Project Plan
Migrating User Desktops and Operating Systems
WinClients@Work: Securing the Desktop
Migrating Applications
Migrating Hardware
Upgrading Windows for Workgroups to Windows NT

Successful Migrations to Windows Clients

For the IT department, half the art of a migration project is to be able to complete the move with as few headaches as possible. A migration or move project is an IT project with the desired end result of relocating something from one place to another.

The first category includes migrations that involve operating systems. Migrating operating systems are potentially major IT projects that require some intense up-front planning. A subset of these operating system migrations would include the migration of a user desktop. When performing either of these two types of migrations, backing up the existing user environment and trying to restore as much of the user's desktop as possible on the new server will be very important to the end user.

Note: Please remember that desktop and workstation are two distinct terms. These days, users frequently work within a graphical user interface, or GUI. Their icons, backdrop, and toolbars are collectively known as the desktop. When referring to the hardware or computer equipment itself, refer to it as the workstation.

Software moves is the second major migration category. These moves are also commonly called migrations. They could involve moving from one operating system to another, from one desktop to another, or from one application to another. While geographic distance is not such a major factor in software moves, the ergonomic distance between the two software products is also proportional to difficulty.

A good example of a moderately difficult software migration could be found during the days of Windows for Workgroups. Users were then familiar with Program Manager, File Manager, and using the mouse. When the Windows 95 interface was introduced, it created considerable resistance among users until they crested the learning curve. While Windows 95 retained some of the familiar mouse functions, it also introduced new items such as Explorer, the Start menu, and the increased use of right-clicking.

Some credit the rise in popularity of Windows NT to the fact that it retained the old familiar interface in NT version 3.51 while Windows 95 was introducing the new interface. Though it was probably coincidence, as the new interface became generally accepted, NT version 4 was released to the market also sporting this new interface.

Hardware moves, the last type of migration I will discuss, usually involve the moving of equipment, such as workstations. Distance and difficulty tend to increase proportionally in these hardware moves.

Stereotypical Users Found in Migrations

In this chapter, I will refer to several migration examples and typical users in the Internet Calendar Company (all the names are made up, of course). You will recognize these common types of users, as it seems that every company has at least one of each type. Knowing the emotional and psychological make-up of your user population will help you to predict the potential reaction of your user population when you have unpopular rollout changes, and it will help you plan how best to handle it.

At the Internet Calendar Company, Julie, a longtime Finance employee, is very picky about her Windows NT desktop. She's gotten everything set the way she wants it and she'll kill the first techno-person who touches her workstation. She has dozens of icons and shortcuts created and lots of links and favorites stored in her Web browser. She has a reputation for abusing the help desk and any technical staff who comes to see her.

Also at the company, Steve from Marketing has a Windows 95 desktop with little more than the standard icons that came with Windows 95. He's not a picky user like Julie, but he does have a problem grasping new concepts, and his attention span is very short at the keyboard. He knows what information he wants, but he gets easily frustrated trying to retrieve it at the keyboard.

Miguel is one of the customer service staff. He's more of a technical user than Steve and Julie, but he's also more of a danger to himself and others than he is an assistance. He frequently bungles things on his workstation for lack of formal training. He has a history with the company of installing games and other software that he found on the Internet on company equipment and he often brings down critical equipment by merely trying to help.

Mark, one of the researchers, is one of those types of users whom you wish there were more of. Hardly causing a problem, Mark works quietly on his system. He calls when he needs help and can easily be walked through many tasks; he is not what you would call a high-maintenance person. He's understanding, practical, and treats the technical staff with respect.

These four types of users can be found in just about any company. They probably immediately brought to mind one of your users and made you declare, "I know that person!"

Each type of user requires a different approach and a different amount of hand-holding through tough times. As you examine different migration scenarios, I'll use this group of four users for reference.

Tip: A migration is also a good opportunity for you to clean up old administrative mistakes. Microsoft inadvertently made many system administrators introduce one such mistake with an early version of Windows NT. In versions 3.5 and 3.51, the default system directory was \WINNT35. Well, those who upgraded from 3.5 or 3.51 to 4 were surprised to learn that they were still stuck with \WINNT35 as their system directory. As you probably already know, you have to reinstall NT completely to use the default system directory \WINNT.

Migration Project Management

Depending on the size of the migration, you may need to complete a project plan to assist you during the planning stages. This plan will document your mission, the goals, and the objective. Your plan should, at a minimum, do the following:

• Name individuals to the project team, including any contractors or consultants.

• State the project definition. The scope, otherwise known as the project's technical

• definitions and desired outcomes, must be clearly stated and cemented in stone prior to project commencement.

• Clearly define the roles of each team member. Avoid ambiguity in leadership roles and reporting structures. Be sure to include regular reports to the project manager from every team member.

• Draw up a schedule of when activities will be accomplished.

• Clearly state the deliverables for the project and their due dates.

These initial steps will help you to construct a project plan that clearly states the objectives to your project team as well as to your management and end users. You can include financial information if you wish; however, be sure to be realistic and make sure that the scope is nailed down and leaves no room for misinterpretation.

Management will be tempted to expand the scope of your project as they see additional opportunities and cost-saving factors. You must resist all efforts to change your scope, as this will lead to increased project costs and missed deadlines. By holding firm on the project scope and sticking to your project plan, you will reduce miscommunications both between your migration staff and the users and between you and management.

WinClients@Work: Sample Migration Project Plan

Here is a sample project plan. The members of the team are fictitious.

I. Project Members

• Dale Baldwin, Project Manager

• Chris Townsend, Project Lead

• Brian Smith, Project Lead

• Richard Nelson, Technical Analyst

• Bill Johnston, Technical Analyst

II. Project Definition/Scope

The objective of this project is the migration of 67 sales employees from Pentium-based PCs to newer Pentium III–based workstations. The project team during the proposed schedule and timeline intends to migrate the sales employees that are currently using Pentium-based computers to newer Pentium III computers. These recently procured computers will be loaded with the standard company load, version 2.1, as provided by the IT department. All other customizations must be requested through the help desk

III. Team Member Roles

Dale Baldwin (Project Manager) will be the primary point of contact for the project. He is responsible for coordinating the project and its deadlines, budget, and deliverables. His chief responsibility is to accomplish the deliverables stated below in support of accomplishing the objective stated.

Brian Smith and Chris Townsend (Project Leads) will chiefly be responsible for the day-to-day management of the migrations to be accomplished. They will supervise and actively participate in the migration of these PCs. Status reports will be sent on a daily basis to the project manager.

Richard Nelson and Bill Johnston (Technical Analysts) will be responsible for the day-to-day activities in support of the migrations. They will be the chief people responsible for the goals and accomplishments of the project leads in completing the migrations within the timelines set out by the project manager.

IV. Schedule

At the commencement of the project, the new workstations will be loaded with the IT workstation load, version 2.1, and tested for approximately two weeks on at least six salespersons' desks. During this time, information relating to what is working or not working shall be given directly to the team leads, who will summarize for the project manager.

Upon successful completion as determined by the project manager, the project leads will draw up a schedule of daily migrations. The targeted pace for the successful completions will be two to three workstations per day. At that rate, it would take an estimated 5–10 working days to migrate the sales department.

V. Deliverables

At the conclusion of the project, the following deliverables will be available to the company:

• The successful migration of all 67 workstations that currently exist in the sales department.

• The satisfaction of users in the sales department. This can be evidenced by user satisfaction surveys conducted at a predetermined time period after the migration is complete.

Migrating User Desktops and Operating Systems

Software companies make an enormous effort to show that their product is easy to migrate or upgrade to. Setup programs and Wizards make migrations sound easy, yet of projects with these features tend to be the most cumbersome. Migrations of operating systems and user desktops are among the most visible to end users and put the IT department in direct and sometimes prolonged contact with them. Thus, the project's success is very important to a continued healthy working relationship with the user.

So what makes this type of migration so difficult? One reason is that users often detect even the slightest differences in their desktop, sometimes despite your best efforts. Some users will unleash their wrath on the nearest person when they notice these differences. When migrating desktops, you want the user to detect little or no differences in the operation and only subtle changes in the overall response times.

Tip: Treat a user's desktop as you would their home. They have likely spent a great deal of time fixing it up the way that they like it. Some users spend more time in their virtual homes than their real ones. If you need to make a major change to a desktop, warn the user first. If there is a potential for disaster, in addition to taking your own precautions, be sure to communicate that potential to the user as well. The closer you can leave the desktop to the original working order, the better.

Disaster Plan

Be sure to have a disaster plan in place should anything go wrong. The issues I see most often surround old files and backing up legacy data. For example, a file that was created in an older word processing, spreadsheet, or database application is no longer supported. Or users might complain that they can't use their new office suite to open up files created in 1987.

The key to surviving disasters like these is backups, backups, and of course, more backups. If you are in an environment that has enterprise backup software such as Legato Networker, Computer Associates' ARCserve, or Seagate Software's BackupExec, then you likely already have the means to back up each workstation. Schedule a backup prior to visiting the user. You should also test a backup or two before relying on them. Everyone has heard horror stories about suddenly discovering that you can't read from a backup tape, making the entire backup process worthless.

I think I've heard a million times, "But I had it saved on the C:\ drive. Things are supposed to be safer there than on the floppy!" I generally put the burden on the users to move their own files to a backup location. They know better what's important to them than I do.

When developing your disaster plan, there are two typical options to choose from in case of trouble. One option might be to replace the nonfunctional workstation with one you know to be working. This puts the user back in operation immediately and allows you to continue troubleshooting the problem away from the wary eyes of the end user. The other option might be to return them to their old working machine temporarily while you troubleshoot. The first option is more efficient and isn't a step backwards like the second.

Whatever the options are, be sure to have a plan ready in case things go south. Avoid divulging copious details of the problem, as many users will be unable to understand the true nature of the problem. This lack of understanding usually causes the end user to feel frustrated.

Migrating Windows for Workgroups

Windows for Workgroups was once considered the must have operating system for peer-to-peer networking. It was also one of the first Microsoft operating systems to have a TCP/IP stack. Before Microsoft released their 32-bit TCP/IP stack, a product called Trumpet Winsock was used to connect Windows-based machines to the Internet.

Back then, if you were assigned to configure the Winsock, you probably found it rather challenging. Combining Windows, Winsock, and any other network protocol stacks to fit inside the DOS 640K memory model was an even larger chore, to say the least. It could be done, but it was sometimes at the expense of applications, which could not run within the limited resources.

Migrating from this operating system requires little more than backing up the user's data and wiping the hard drive. If you have 16-bit programs that you must still support, consider upgrading to the 32-bit versions. The advantages to the user and the help desk are well worth the additional cost. While NT supports a respectable number of legacy applications, keeping these applications does create a number of support issues and taxes the available resources on the workstation.

Whenever you switch operating systems, two elements tend to be in short supply: planning and training. No amount of either seems to be enough. Surprises always seem to occur. You can combat this by setting up classes to get the users past the unfamiliarity barrier and remove their apprehension prior to a migration. Unless it is taboo in your organization, be sure to point out that the familiar games such as Solitaire or Minesweeper are still installed.

You should always conduct this training prior to the actual rollout. If it's completed afterwards, the user is likely to come to the class hostile with a list of questions in search of answers. Once they have their answers, users tend to block out new information and any additional training efforts may be wasted.

Migrating Windows 95 to Windows NT

Migrating from Windows 95 to another operating system can be rather simple—or it can be rather tricky. Moving to Windows 98 is a long upgrade, but it's one that can be completed with little intervention. Moving to NT, however, is a bit different. Because of the incompatible registries, you cannot migrate any of the Windows 95 settings into Windows NT.

In planning a Windows 95 to NT conversion, you must first check to see which applications will be supported under NT. Many applications that ran well under 95 either will not run or will be incredibly inefficient. Often a manufacturer will have an updated 32-bit NT version to replace the 16-bit version that you have been relying on. Don't forget drivers or other support software that you will also have to convert. Many 95 drivers are not NT compatible. Manufacturers will likely have other drivers available that are designed for NT.

Some of the concerns that I usually have when upgrading a client system from 95 to NT Workstation are listed here.

• Device Settings What device settings will I need to properly configure device drivers? Remember that Plug-and-Play devices will have to be configured manually.

• Increased Hardware Requirements While the minimum hardware requirements will just get you by for now, the recommended usually isn't ultimately enough. Go for the highest level hardware you can afford now and you will have to upgrade less later.

• New Drivers Will you need new drivers for the hardware under Windows NT? Many drivers are not compatible or have special NT versions written just for them.

WinClients@Work: Moving from Windows 95 to Windows NT Using Leased Equipment

The Internet Calendar Company needs to upgrade the Accounting/Finance department from Windows 95 to Windows NT. All company applications must be migrated over to the new operating system. The new desktop should look the same as the old.

Problem

The operating system migration will not only be costly but time consuming to implement. Some hardware will not be compatible with the new operating system, prompting additional hardware costs. Some applications will not run under Windows NT.

Approach

Management has appointed a committee to study the applications that have been identified as being incompatible with Windows NT. They have also been asked to identify the advantages and disadvantages of leasing equipment rather than purchasing it.

These days some mid- and large-sized companies are turning to leasing workstations and servers rather than purchasing. One big advantage here is at the end of the lease period (usually three years) the outdated equipment goes away, no questions asked. You can sign another lease for state-of-the-art servers and workstations. The downside is that because the equipment is merely rented, there is no tax-deductible investment to show for the lease payments.

Hurdles

Signing a lease requires involvement from other areas of the company. This involves a shift in managerial direction, which will drag in corporate administrative types. Any tax changes resulting from the inability to depreciate assets will interest accounting and financial employees. The contract will demand the attention of the legal department, who will have plenty to say about the language of the contract. To overcome some of these obstacles, use some of the metrics from Chapter 1, such as discussing the expected life cycle with these departments. Show them the business reasons to lease or purchase.

Suggestions

• The migration to NT will involve some minor changes to the user. They will have to provide a login name and password in order to use any services, for instance. Their ability to install software may be also restricted by the administrator. These changes should be discussed with the user in advance.

• Ask the user to migrate their personal data to a shared network drive or other temporary storage place during the conversion. If you put the burden of moving the data on the user, there will be fewer mistakes regarding the safety of the user's data.

My Solution

First, have the company lease machines from an approved list rather than haphazardly purchase new equipment. This will allow me to settle on a company standard for the workstations that other system administrators can follow.

Second, develop a standard desktop that all new machines will receive. Be sure to place program locations in their common default directories across all machines.

Third, hold classes on the use of Windows NT Workstation. Be sure to provide plenty of hands-on experience.

Migrating Windows NT Desktops

In most cases, upgrading from one version of NT to another is not a catastrophic event. Moving from NT 3.51 to 4 is generally an easy upgrade from the technical perspective. It is the users who will perceive it as the big switch and the life-changing experience. This highlights the most difficult challenge in network computing: upgrading the user.

I've seen the worst conflicts arise over the desktop appearance and who should be able to customize them. It usually begins after a long history of users having free reign over their desktops and being able to install anything that looks cute and is available to them inside the Web browser or was sent to them over e-mail. I frequently get "cute" programs sent to me unsolicited via e-mail. You probably have seen these: the dancing baby, screen savers with frogs, science fiction desktop themes, and so on. The truth is, these elements increase support costs tremendously.

The end result is that management has to step in and quash the personalized desktops and institute a department-wide, or better yet, a company-wide standard for desktops. In Windows NT, this can be accomplished through the use of policies and user profiles. Just moving from a nonstructured NT environment to one that is tightly controlled is an operating system migration by definition and will likely be the most difficult upgrade ever because of user resistance.

User Profiles and Policies

User profiles and policies have been around for some time now. User profiles and mandatory profiles existed in version 3.51, if only in a crude form. To create a user profile required a lot of work on the administrators' behalf, including a lot of logging off and on.

In version 4, both profiles and policies began their rise to fame. Administrators finally had a way to edit profiles without pretending to be that user. Though a user receives a copy of the default user profile under Windows NT 4 to use as their own profile, you can change the profile to become read-only or a mandatory profile. Another method is to use policies to restrict changes to the profile.

In the following example, Internet Calendar Company users will be moved to a standardized desktop in order to cut down on service costs.

WinClients@Work: Securing the Desktop

The IT department of the Internet Calendar Company has been plagued with support problems stemming from users accidentally reconfiguring their desktop.

Problem

Some users inadvertently delete or otherwise obscure from view vital desktop icons, resulting in a phone call to the help desk. Other users customize their desktop with untested objects such as icons, fonts, and backgrounds. The NT domain structure is a Single Domain Model. Internet Calendar Company users such as Julie and Miguel will have a difficult time not being able to add applications to their system.

Approach

The change committee of the IT department has decided that the most cost-effective approach is to lock down the desktops by implementing Windows 95 and NT system policies and prevent users from making changes. This approach has been given the go-ahead from management and should be implemented within a reasonable time period, proposed to be 60–90 days.

Your approach should minimize the impact to existing users. It should also give you the ability to adjust the desktop without having to visit each user.

Hurdles

Users will not take kindly to their desktop changing, let alone being restricted. You will have to frequently remind users of the needs and benefits of such a plan. Standardized desktops will save money in the form of support costs and recovering lost end-user time.

Suggestions

• Test the desktop and look for minor inconsistencies such as bad paths and broken links prior to deployment will reduce complaints.

• Publish a list of applications that will be on the new desktop. Clearly state the procedures for adding applications or making changes to the desktop at the individual, group, and company-wide level.

• Once you have moved to the standard desktop, you will initially receive many requests for additions to the desktop. Carefully study each request and think of the overall impact at the macro level rather than just on the surface. You may solve one user's problem and create dozens of problems for other users.

My Solution

I wanted to quickly develop a guideline to define company-supported applications. Once this list was defined, I created the first desktop. I created a new global group called UserDesktop. I developed a system policy for this group that redefined the desktop, Start menu, programs folder, etc., to common UNCs. This desktop was heavily tested, and users were slowly converted to it. Permissions to these UNCs were set to read-only to prevent inadvertent changes.

As a matter of precaution, a new NT Workstation load or deployment was developed to ensure that all the new workstations had the same load with the program paths in the same locations. Each new user had their personal files backed up to their network share and their workstations were reloaded. While Julie and Miguel may have a difficult time with the new desktop restrictions, the new restrictions will cut down on trouble calls from Steve and Mark. You could spend some additional time before the change to visit with Julie and Miguel to help soften the impact they will feel. In the long run, this will make for happier users and a happier help desk.

When migrating users to a new user profile, be sure to test it thoroughly. There will be tension as the user tries out their profile for the first time. Be sure to test beforehand any NT policies that may be in place.

The testing that you do beforehand will help you greatly later. Remember that it is much easier to give than to take away. This applies to applications, environments, file permissions, and administrative rights, among other things. It is so easy to give them out, and you tend to get rewarded by users when you do. But taking things away is an entirely different matter.

Once you have implemented a strong policy that prevents user updates to profiles, you must adopt a firm approach to relaxing or changing those policies. There will be many users who will want special applications loaded just for them. You must find the strength to resist these challenges, as special programs will eventually cause trouble arising from inconsistency down the road.

I know of a site with over 30,000 standardized desktops, and it literally requires an act of Congress to have anything added to the desktop. This may sound heavy-handed, but in the long run, many support dollars are saved. Incidentally, the testing process for adding new applications at this site is brutal. Applications that potentially interfere with the existing infrastructure do not survive this test.

I have also seen software review boards used as a good tool to use for evaluating applications. Having a board turn down a piece of software carries much more weight than just an individual saying, "No." These boards can objectively look at the need for the application, the proposed application, and the expected end result.

Mass Migrations

If your migration project requires that you set aside large blocks of time for IT professionals to complete the tasks or you must bring in outside vendors, then you probably have a mass migration situation. This type of situation requires formal project management planning to keep people on task and the project under budget.

Migrating Applications

Applications become migration candidates for the smallest of reasons. It usually begins with a single feature that someone decides that they cannot live without. They may not always speak up right away other than to point it out to a coworker. But I've noticed that once someone is convinced they need either an upgrade or a competitive application (sometimes called a sidegrade), the reasons they need the new application begin to swell until others join the ranks and a majority emerges. Pretty soon, here comes the directive to the IT department from above: "Give them what they want." Then it usually cycles the course again to decide who gets to pay for it.

In the early 1990s, a battle emerged around the country over what office application suite to use. People were then militant over their choice of word processor and ready to attack their competitors, citing the pros and defending the cons of their choices. While this battle still rages on in some offices around the country, for the most part the war is over. I won't mention who won, or you might think I'm biased. But this should prove to you that it is important to consider office politics when migrating applications. Ignore them, and you will pay the consequences.

Office Politics and Applications

There are few places of employment where politics do not play some role in the daily operation of the office. Gossip, rumors, and secret talks with other workers can sometimes have more powerful effects than the highest of leaders. Office politics have managed to bring more than one person down, even if their intentions began as honorable. Failure to recognize this power can spell disaster.

You're probably wondering what politics and migrating applications have in common. In the last section, I mentioned to you that users value their environments and treat them like their own homes. I tend to take better care of my desktop than I do of my real house, when it comes to cleaning out old items. Well, applications have similar effects on users. They tend to know an application's behavior better than we support-people do. If management decides that it is necessary to make a change that isn't in IT's best interests (such as doing something absurd like opening all the ports on the firewall to allow NetMeeting sessions to take place), then the IT staff had better come armed with some good reasons for it or their users will have at least as many good reasons not to make the switch!

Fighting Office Politics

I have worked in many environments in which politics ruled the office. One in particular proved especially challenging in that I was only one of a handful of technical people. I had to convince the office that an application needed a major upgrade. The users previously relied on a clerical person to enter data and generate reports. Since I already know the outcome of this upgrade was a success, why don't we just adopt this as our next example project?

When I first discussed the possibility of such a project with the rank and file, it didn't take long before I met with resistance. I needed to prove that the end users should enter the data and not the clerical person. No one wanted to take on the additional responsibilities of data entry without getting more money. I had to think of a way to get them to want to change. I did this with the carrot approach.

How to Win Over Your End Users with the Carrot Approach

The carrot approach means that you give your users something fun to do in exchange for learning your new program. An example would be when users were given the Solitaire game to teach them to point and click in the early days of Windows. I think even the explosion of the Internet can partly be attributed to the carrot approach.

The early days of the Internet, which consisted of plain text e-mail, FTP, Telnet, and Gopher, were eventually overrun with the then-novelty of graphics-laden and content-rich HTML. Small movies and MP3s were the carrots that pulled many users (including myself) away from other computer multimedia technology, even if the pictures and sound were inferior. Figure 3.1 shows the Web browser, Mosaic, that started the HTML craze. Mosaic stopped producing browsers in 1996.

Tip: Give the users something they don't already have—something that they may or may not realize they want—but let them know that they have to do what you want before they get it.

Figure 3.1: National Center for Supercomputing Applications, otherwise known as NCSA's Mosaic Browser version 3. This was the last version produced of the browser that started it all.

I recently applied this same methodology to an Exchange/Outlook conversion. The users were quite comfortable with using their Eudora e-mail programs, but the company wanted to move in the direction of shared calendaring and public folders. I demonstrated a working Exchange and Outlook environment to their entire staff, showing them all the neat things they could do only if they would give up their existing e-mail packages. We picked on a receptionist and asked if she had trouble checking calendars to find free time for meetings. She wasted no time in relaying her frustration from past incidents of trying to coordinate meetings. We demonstrated how easy that could be with Outlook and Exchange. From that moment forward, we could say no wrong. She had to have that software.

During the rest of the presentation, we mapped out to the users other tasks that Outlook can perform. By the end of the presentation, several attendees were anxious to know when the software would be installed on their machine. They spent the remaining days before the migration with their old software, cleaning house and effectively reducing their storage requirements.

I also set up a team to test the software for nearly a month before I did the conversion. We trained the gung-ho employees that we knew would assist others users to help us be successful. The rest of the users got some minor training just prior to the rollout so that their first day with the product would not be so traumatic. Overall, the migration was a success.

WinClients@Work: Migrating Applications While Soliciting End-User Support (The Carrot Approach)

Problem

To solicit user support during an upgrade in the Internet Calendar Company's Sales department while giving the end user (salespeople) more responsibility. This environment depends on a business-critical application for most day-to-day functions. Upgrading the application can no longer be put off.

In the Internet Calendar Company, the sales staff has always relied on clerical staff to enter sales orders and generate packing lists. Because of several clerical errors due to poor writing skills by the salespeople, it was determined that salespeople should take advantage of the company's technology and learn to enter their own tickets. This would remove the clerical staff from the loop and free them for other duties.

Approach

Evaluate the user base and identify whose opinions count in the office and who will actually use the application. Hold study sessions with them on the new software. Allow them to participate in selection teams and any minor decisions to be made.

Offer them Web access (the carrot) at the same time you introduce the new application. Be sure to mention to the user community that the new application is only possible because of the carrot (but don't call it a carrot!).

Hurdles

Motivating the salespeople to use the computers to enter reports. Training employees on the new system.

Suggestions

• After the testing is over, require your naysayers to help support the new users of the application. You will find that the naysayers will feel empowered and a sense of trust will develop between you and the naysayers.

• Avoid letting people sit on the fence and use both the old application and the new. If you must, provide a cutoff date for which the old application will no longer be valid.

My Solution

The transition was going to be bumpy with lots of problems and questions by the users. If things went sour and the users complained too loudly, management would step in and quell the situation, which would most likely end the project.

I circumvented the naysayers in the group by allowing them to be the first to try the new software. This created a positive buzz around the workplace because the naysayers felt privileged to be able to do something the rest of the gang could not.

Once the naysayers were comfortable, I let them pick whom we should train first. Of course, they picked their friends and coworkers. I scheduled the first two training classes this way and then trained the rest on my schedule. At one point, those who had not been exposed to the software were clamoring to get in.

I've used the carrot approach extremely often. It is a great way to get users past the negativity of being forced to use a new software package as delivered through a software-based migration or software move.

Migrating E-Mail Packages

Just like desktops, e-mail packages have become property that is considered private as well. As a result, users have an inherent expectation of privacy. They consider their e-mail to be confidential. By today's standards, unless otherwise specifically agreed to in writing beforehand, you need a court order to open someone else's mailbox.

It is not difficult to imagine how users must feel when you come knocking, wanting to migrate e-mail packages. (You won't usually have as much trouble upgrading versions of e-mail applications as you will switching from one e-mail program to another.)

The toughest part of the migration is usually the client expectations. E-mail packages are usually small packages with small footprints. They do not cause much trouble during installation; however, I've seen some problems when mixing manufacturers, for example, using Microsoft Office products on the same desktop as Corel. They both use dynamic linked libraries (DLLs) with the same names, and, during installation, these DLLs go stomping on and disabling one another.

Warning: Avoid importing old e-mail at all costs. Try to make a clean break from the old e-mail system, and you will have far fewer headaches and save a lot of money on the migration.

Migrating the e-mail boxes from one package to another is one of the most time-consuming tasks that you can do. I have been on projects where the big bosses wanted thousands of archived e-mails transferred between e-mail programs. There sometimes is no simple way to transfer these. Avoid this route at all costs. Some programs claim to import existing e-mails, but I've found that over the long run, they don't completely match all of the fields involved. I once performed a Eudora-to-Outlook conversion in which Eudora's Sent-to: e-mail field did not completely match up to the Outlook importer, resulting in blank Sent-to: fields in tens of thousands of messages that were imported for the project. This made the import next to worthless.

Also, be sure to understand the impact on personal distribution lists and address books. Be sure to warn the end user if these will not migrate. Even if you do not migrate the e-mail, remove or disable the old e-mail program on the workstation so that users won't try to continue to use the old application.

Migrating Hardware

I have extensively covered software moves but have hardly touched the hardware side. Hardware migrations tend to be easier than software migrations, as the new speed of the systems generally impresses the users. They are usually so frustrated with the old systems that they are glad to get the new ones.

Occasionally, there is an opportunity during hardware migration to consolidate systems. There are advantages to standardizing on a hardware platform. For instance, agreeing that a certain model of PC will be supported before procurement will make things easier for the support team. Standard workstation loads can be developed (this is covered extensively in the next chapter).

Leasing Programs

Small businesses are frequently plagued with how to budget IT components. A certainty is that small business cannot survive today's business world without computers. Small businesses, however, cannot afford to keep the latest and greatest workstations in front of them. Many will hold on to their PCs for five or more years, sacrificing in order not to have to spend the money it takes to keep current.

Some of the major manufacturers have leasing programs that make the PC more affordable. The most obvious benefit to the leasing option is that at the end of the lease period the small business can usually replace the hardware on their desks with little or no change to their monthly lease payment.

Leasing is also attractive to large businesses, as they do not have to make large storage rooms available for storage of older systems while they decide how to best dispose of the equipment.

A benefit to every size business is that leasing makes it easier to standardize on one type of computer. This cuts costs on support and makes life easier on everyone. Standardized workstations and desktops are the easiest and most inexpensive models to support. Leasing can help deliver that.

Methods for Migrating Hard Disks

In some instances, it may be necessary to clone portions of the hard disk from the old machine to the new machine. Sometimes you may wish to clone the entire disk. I mentioned some great tools for that in Chapter 2 that will allow you to make a completely identical image of a hard drive, such as Ghost and Drive Image Pro.

But in some cases, there may only be a need to transfer certain directories and files, and there is no network connection available. A good null modem and direct connect software works well in this scenario. A program I've used in these instances is Laplink by Travelling Software. They have built some new features into this old DOS favorite, and they now support multiple operating systems such as Windows 95, 98, and NT. They can transfer files over the USB port and now support remote control of desktops.

Note: You can find out more about Travelling Software's Laplink at https://www.laplink.com.

Upgrading Windows for Workgroups to Windows NT

The IT department of the Internet Calendar Company has finally found enough money in its budget to replace the legacy Windows for Workgroups 3.11 machines in the legal office. They will be replaced with state-of-the-art workstations that are preinstalled with NT 4, speedy processors, and tons of memory and disk space. They will come configured with premium sound cards and speakers and with a DVD-ROM, which gives them the ability to view video and movies.

Problem

This department is fraught with users similar to Julie from Finance and Steve from Marketing. There are some who have had their desktops for over five years, feel very protective of their desktop, and will be very resistant to change. Users like Steve will be very difficult to retrain on the new desktop. While there are a few Steves in this world who really don't want to learn, there are many more for whom you have just not yet found the right carrot. Don't give up on the difficult ones; stick by them and learn when to temporarily retreat if the user gets too hostile. In these cases, it is more productive to retreat and re-engage later when the user is calmer.

Approach

The key to this problem is to avoid landing new surprises on the users. Identify the managers of those who you have to migrate and show them the reasons why you must migrate. If you solicit their buy-in up front, the user will be less likely to turn on you if anything goes wrong. Work with the users ahead of time and be sure to provide them with plenty of warning when you are altering their workstation environments.

You can also tell your users that the new equipment will be much faster and will have more room to store files. Many users will be glad to take newer and faster equipment. (The task suddenly gets harder, however, when you have to recycle old equipment.)

Hurdles

As you're installing the new system, the user will always be thinking, "What does this change for me? Whatever this person is doing will probably screw up my machine. I'll never be able to work right again." Remember, they are already thinking negative, even if they are looking forward to the change.

Suggestions

• Set up a company lab or acquire a demo copy for the user to try at home so they can start to play with the new operating system before it is rolled out. Sometimes, it is even cheaper to purchase a copy of the workstation operating systems for the users at home than it is to train the user on the job. Calls to the help desk will become less frequent as the user spends more time with the new operating system and becomes more acclimated to it.

• Target the users who will likely be the most vocal or critical about the project to be the first to receive the new product. Try to afford them special treatment and extra attention prior to the project and introduce them to the new product away from their desk. This way, they will absorb that change is coming. Don't leave any questions unanswered, or it will surely result in criticism later. Each user can usually find something about a new product they like. You must identify what that something is for this group ahead of time.

• If possible, have all configurations completed before you arrive to swap equipment. Avoid making negative comments during the swap, such as, "Uh-oh!" or "What's this?" or "This is interesting." These remarks will create user anxiety and will certainly lead to negativity about your project on the user's part.

My Solution

Legal did not have many users; therefore, our study group consisted of just a meeting or two. I had sandwiches catered into the conference room (a nice gesture that gets the staff to focus energy on something besides attacking me) and demonstrated the new operating system. The demo lasted only 20 minutes or so, leaving another 15 minutes for questions. At the end of our session, I handed out company-purchased copies of the new operating system for users to try at home.

Prior to the actual desktop conversion, I picked a user who was very vocal in the group and had them test the new system. Always target the most vocal users when rolling out new software. These users, as allies, can help the overall project. As enemies, they can quickly and easily quash your chances at success. I pointed out to the vocal user the additional speed and new features on the new desktop. I waited about a week after this demo before starting on the conversion. I gave the users at least a good 48 hours to back up their important data.

During the conversion, I talked with users about the new features and improvements over the old desktop. You can usually get the user to tell you about bad experiences with software and hardware so that you can show off the new desktop, hence making the user feel more open to the new desktop.

After the rollout was over, I checked back with our vocal employee to see how things were going. Though they still remained skeptical for a few weeks as they became more familiar with the new desktop, they are now happy with the end result. Follow-up is the most important step—to show genuine concern and be responsive to the concerns of the user.

Tools Used

In this scenario, I was migrating from Windows for Workgroups to NT4. There are no profiles to save other than to try to get 32-bit versions of their popular 16-bit applications. Since there are no profiles to save, it is a brand new desktop. You could relocate user data to a network share for the time being, until the desktop is complete.

About the Author

Allen Jones is a Microsoft Certified Trainer (MCT) and Microsoft Certified Systems Engineer + Internet (MCSE+I) with more than 15 years of networking experience. He is a project manager and consultant for Sprint Paranet, where he specializes in LAN/WAN management and integration of BackOffice servers. His other books include MCSE Test Success: Internet Explorer 4 Administration Kit, also from Sybex Network Press.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

Click to order