Computer Life Cycle Management and Migration
Published: June 1, 2008
Managing IT equipment and product life cycles is an important function of IT department staff.
The year is 1999. The place – a small branch of a national financial institution. For months, the company’s analysts, managers, IT staff, test users and help desk staff had planned for every contingency for their Y2K migration. After the first day of rollout, someone realizes that some of the bankers and tellers had been posting their transactions to the old system instead of the shiny new one. Why? “Because it was still working fine! We were able to make it keep working for us!” Despite all of the training, usability studies and fine-tuning of the new Y2K system, no one was able to prevent users from accessing the old system, which needed to stay running for the remainder of the branches who would migrate at a later date (but would not be posting transactions for that particular branch). Fortunately, paper transaction slips could be re-processed and no customers lost their money. The migration team learned a valuable lesson that could be applied to the rest of the branches, and the Y2K migration was a smashing success.
Every IT professional can tell a horror story about an upgrade, rollout, 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 percent over the same period in 2006. Global PC shipments during 2007 increased 13.4 percent 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.
Those in IT 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 road map. 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.
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:
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. Notice the graph below from Gartner RAS Core Research detailing Microsoft’s main products for the next five years.
Source: Gartner (September 2007)
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 include:
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.
Sean Barry - Sean is a senior data recovery engineer with Kroll Ontrack, the largest, most experienced and technologically advanced provider of data recovery products and services in the world. He also serves as a training coordinator for the data recovery department. In April 2006, Sean was a guest speaker at Ontrack's Data Recovery Symposium. Sean has been with Kroll Ontrack since 1997. He’s been instrumental in supporting and developing numerous technologies for the company and focuses on providing the highest quality data recovery solutions for computer data disasters.