Computer Life Cycle Management and Migration

Every IT professional can tell a horror story about an upgrade, roll-out, or migration gone awry. So
many factors are involved; hardware, software, compatibility, timing, data, procedures, security
protocols, and of course the well-meaning but imperfect human.

Over 2008, IT departments and staff can look forward to a number of upgrade projects for their
computer system infrastructure. According to Gartner, Inc., the number of PC shipments during
fourth quarter 2007 increased 13.1% over the same period in 2006. Global PC shipments during
2007 increased 13.4% over 2006—equating to 271.2 million units in 2007.

While a slower economy than in previous years may lower the number of units, the fact that
organizations have been investing in new units shows that hardware life-cycle management is still a
mainstay of corporate IT’s responsibilities and will continue to be such.

IT professionals realize that scheduled change is a pattern for the industry. Whether this change
involves accommodating new users, replacing old servers, or upgrading staff to newer systems,
there is always change within the computer organization. Sometimes it is easy to only rely on
hardware or software budgets for your roadmap. However, these budgets may be short-sighted and
lack proper planning. Using accounting budgets alone to manage hardware may not take into
consideration the overall life span of the equipment.
Equipment /Software Life-Cycles and Your Road Map

Managing IT equipment and product life-cycles is an important function of IT department staff. As a

goal, equipment life-cycle management should reduce failures and data-loss because computer
equipment is replaced before it fails, and it should reduce the total cost of equipment management
over its lifetime. Depending on the organization, equipment life-cycles are based on different
criteria.

• Capital expense budgets: Some IT departments base their product life-cycles on

departmental accounting policies for capital expense purchases. Of course, this alternative
method can have a knock-on effect when there is a business need for expansion and this
wasn’t considered in the fiscal budget. Additionally, in larger user environments,
departments may have control of their own capital expense budgets, so there may be many
departments with different budget needs. When the life-cycle of one department’s
equipment is complete, the number of fragmented purchases may actually reduce your
company’s buying power. In contrast, a more structured approach would concentrate
equipment purchases to various times throughout the year. This method is preferred by
CFO or budget managers who will use a predefined purchase allocation per business unit or
department to facilitate budget planning for the next year.

• Warranty expiration: If your IT infrastructure has a mix of equipment in place, with

different makes and types of equipment, then your warranty-based product life-cycle
management will be complicated. Using this approach is not only short-sighted, it also
mirrors the first time you bought the equipment. Consider the expanding department who
needs to plead with the CFO or budgetary manager for a non-planned equipment purchase.
Three years later when the warranty expires, the department will be back again on their
knees begging for replacements or an extension to the expiring warranties. Whichever the
case, it will be an unplanned expense.

• Waiting until equipment fails: In our economy, budgets are tight and management
rightfully wants to get the most production or usage out of a piece of equipment before
having to replace it. This approach is very risky and will usually cost more in the end. IT
equipment rarely fails at a “convenient” time. If you’re lucky, the failure occurs during a
slower period and your IT department is equipped to get you back up and running quickly.
In reality, this is not usually the case. Consider the real cost of equipment failure if it is
month-end or year-end and the server with the financial data crashes; or a company has
just secured a large contract and at the eleventh hour, one or more workstations fails or
becomes intermittent causing wasted downtime on the project and inefficient use of
personnel resources.
There are a number of financial planning exercises that can help you determine if capital expenses
for PC hardware with complete parts and service contracts for the life of the unit are best suited for
your IT infrastructure. Alternatively, leased IT equipment may be more cost effective and would
assist in maintaining a more comprehensive IT equipment life-cycle program.

As we dig further into this topic, you will see that hardware and software deployment planning is
just the start of discussion for the IT group. Migration planning raises more questions than answers
and these questions start with equipment and software life-cycle management. For example,
planning discussions can start with these questions:

• What is your IT department’s roadmap for equipment management?

• How about the users you support, does your roadmap align with their needs?
• What requirements have inter-company business owners or department managers
contributed to the overall equipment management policy? Are any of the suggested
requirements based on some of the above mentioned methods? (i.e., does the accounting
department determine the life-cycle or does the OEM warranty determine the life-cycle, or
is the policy just to “run the equipment into the ground”?)

Visualizing the product map of the software your organization uses and planning your major
equipment purchases within a timeline helps structure your hardware retirement strategy. By
synchronizing your hardware purchases with your software investment, you can minimize large
capital expenditures and stagger departmental purchases so that you can qualify for volume
discounts.

Additionally, if your organization qualifies for specific licensing models, you may be able to plan your
software purchasing on alternate years from your hardware purchasing. Take Microsoft’s core
software products as an example (Fig. 1).

Figure 1: Recent Microsoft® software product launches

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
Windows Server 2000 Windows Server 2003 Windows Server
2008
Windows Windows XP Windows Vista
2000
Exchange Server Exchange Server Exchange Server
2000 2003 2007
SQL Server SQL Server SQL Server 2008
2000 2005

It is tempting to think that only hardware equipment has a life-cycle, yet the above example clearly
shows that software too has a life-cycle. Could your IT infrastructure benefit from synchronizing
your life-cycle management of both PC hardware units and software licenses? Where does your
organization envision product adoption and integration with respect to manufacturer rollout? Finally,
does your PC hardware for servers, desktops, and laptops or notebooks align with or complement
that vision?

Planning for a Migration

Planning for product life-cycles necessitates an implementation strategy. Migration of computer

systems has evolved from the manual process of a complete rebuild and then copying over the data
files to an intelligent method of transferring the settings of a particular system and then the data
files.

Many IT professionals can attest to the fact that there is a large investment in time and fine tuning
of new servers. Whether it’s complexity of domain controllers, user and group policies, security
policies, operating system patches, and additional services to users—all of these require time to set
up. Fine tuning the server after the rollout can be time consuming as well. Once completed, a
computer system administrator wants to have the confidence that the equipment and operating
system are going to operate normally.

Thought needs to be given as well to the settings and other customization that users have done on
their workstations. Some users are allowed to have a number of rights over their machine and can
thus customize software installations, default file locations to alternate locations, or can have a
number of programs that are unknown to the IT department. This can make a unilateral migration
unsuccessful because of all of the unique user settings. The aftereffect is a disaster with users
having missing software and data files, lost productivity as they re-customize their workstations,
and worst of all, overwritten or lost files.

Deployment test labs are a must for migration preparation. A test lab should include, at a minimum,
a domain controller, one or two sample production file servers, and enough workstations, sample
data, and users to simulate a user environment. Virtualization software can assist with testing
automated upgrades and migrations. The software tools to do the actual migration are varied—some
are from operating system software vendors, others may be third party applications or enterprise
software suites that provide other archiving functions. There are a number of documents and
suggestions for migration techniques (some are listed in the references).

The success of a migration rests on analysis, planning, and testing before rolling out changes. For
example, one company with over 28,000 employees has a very detailed migration plan for its users.
The IT department used a lab, separate from the corporate network infrastructure, to test
deployments and had a team working specifically on migration. The team had completed the test-
lab phase of their plan and the migration was successful in that controlled environment.

The next phase was to roll out a test case on some of the smaller departments within the company.
The test case migration was scheduled to run automatically when the users logged in. The migration
of the user computers to a new operating system started as planned. After the migration, the user
computers automatically started downloading and installing software updates (a domain policy).
Unfortunately, one of these updates had not been tested. The unexpected result was that user
computers in the test case departments were inoperable.

Some of the users in the test case contacted the IT Help Desk for assistance. IT immediately started
troubleshooting the operational issues of the problem without realizing that this was caused by a
migration test case error. Other users in the department who felt technically savvy tried solving the
problem themselves. This made matters worse when one user reformatted and reinstalled the
operating system and overwrote a large portion of original data files.

Fortunately for this company, their plan was built in phases and had break-points along the way so
that the success of the migration could be measured. The failure in this case was two-fold in that
there were some domain policies that had not been implemented on test lab servers, and the effect
of a migration plus the application of software updates had not been fully tested. The losses were
serious for some users, yet minimal for the entire organization.

For other migration rollouts, the losses can be much more serious. For example, one company’s IT
department created a logon script to apply software updates. However, an untested line of the script
started a reinstall of the operating system. So as users were logging into their computers at the
start of the week, most noticed that the startup was taking longer than usual. When they finally
were able to access their computer desktop, they noticed that all of their user files and settings
were gone.

The scripting problem was not seen during the test lab phase, IT staff said. Over 300 users were
affected and nearly 100 computers required data recovery services.

This illustrates the importance of the planning and testing phases of a migration. Creating a test
environment that mirrors the IT infrastructure will go a long way toward anticipating and fixing
problems. But despite the most thought-out migration, the most experienced data professionals
know that they can expect the unexpected. Where can you turn if your migration rollout results in a
disaster?

Migration Disaster-Recovery Options

Even the best planning for any deployment can result in disaster for users and critical data. In order
to be completely prepared, include data recovery planning within your plan. Questions for your team
to ask are:

• How do we handle an unexpected event during the deployment process?

• Do we have enough break-points within the automation to catch errors?
• Can a backup be performed before the deployment?
• How much time or resources would it take to recover from migration disaster?
• What alternatives do we have if there is a hardware failure during the migration?
• What data recovery vendors do we have relationships with that can get back our data in a
timely way and also maintain quality?

Being prepared for the worst ensures the greatest success. Think seriously about the disaster
recovery side of the project and build in data safety processes so that data loss is minimized.

In the event that a deployment causes widespread accidental data loss, or that key systems or
workstations are affected, know when to stop and get professional data recovery assistance. Many
times data loss goes from serious to disastrous because inexperienced IT staff work to resolve the
problem. After running software found on the Internet in a panic, the data loss becomes more
severe. When all internal options are exhausted, a professional data recovery firm is finally
engaged. Not only has precious time been lost, the damage to the data has increased or becomes
unrecoverable.

All data recovery companies and offerings are not the same. Data recovery companies that claim to
specialize in data recovery, yet in reality use off-the-shelf recovery tools are far more limited in their
capabilities.

Kroll Ontrack has demonstrated its expertise, dedication to research and development, and
consistent track record for producing quality recovery solutions for over 20 years. We know that
data recovery is a science—a discipline that requires trained experts.

References

• Gartner Press Release (2008), “Gartner Says Worldwide PC Market Grew 13 Percent in
2007” (html link), Gartner, Inc.
• Robert Frances Group (2005), “The Downside of Keeping PCs beyond Three Years and
How Leasing Can Help” (PDF), Robert Frances Group, Inc.
• Adam Braunstein (2006), “A Rationale for PC Leasing and Refresh: Risk Mitigation” (PDF),
Robert Frances Group, Inc.
• John Enck (2007), “Windows Server 2008: When You Should Care” (html link), Gartner, Inc.
• Microsoft TechNet (2007), “Microsoft Deployment Test Feature Team Guide” (html link),
Microsoft Corporation
• Frederick W. Broussard (2007), “Best Practices for Windows Vista Planning, Migration, and
Ongoing Management” (PDF), Symantec Corporation, IDC