When it comes to migrating from an established product to a new version, the IT decision-maker steers a path between the devil and the deep blue sea. There are always plenty of people desperate to get you on to the latest version of whatever product it may be.
In the case of an operating environment such as Windows 2000, clamours may come not just from suppliers of the product, but from companies touting implementation assistance, software houses with migration aids to sell, and maybe hardware suppliers that know you will need faster chips. Inside your own company, there will be factions eager for change, especially in the IT department - not just because of the excitement (and career advantages) of finding out about the latest technology, but because they genuinely perceive there are improvements to be gained. Eventually, too, pressures may come from end-users because the applications they want to use are not available or not supported on the current operating environment.
On the other hand, the IT manager usually hears plenty of arguments against change. Particularly with a new product, it can be difficult to convince the board that the cost and disruption of a change is justified (though in the case of Windows 2000 there are reports of business managers, too, succumbing to supplier hype).
There are always other projects crying out for funds and resources, and it can be unappealing to prioritise an operating system upgrade over something with more visible results, such as an e-commerce implementation.
Unappealing, too, is the prospect of substituting an untried environment for one that is comfortably bedded in. "No IT manager wants to experiment on a corporate network for which they're responsible," points out Computer Weekly's guest editor Peter Mansbridge, group IT manager with the Chloride Group. He adds, "The only possible exception is where the company is so hi-tech that adoption of new technology is essential to their business strategy."
Leaving aside these business-critical corporate fashion victims, how can the decision-maker reconcile the conflicting pressures and pinpoint the optimum moment to migrate? For Mansbridge, the starting point is constantly to match IT plans to business strategy and competitive edge. "On the one hand, you have the chief executive officer with objectives like increasing market share, increasing total shareholder returns, and so on. On the other hand, you have the IT people saying 'look what we could do with the Web site if we were to upgrade to such-and-such a product'. In planning a migration, it's important to find a way to bridge this divide."
That means mapping the technical benefits to the business's objectives - thinking about how an enhancement to a Web site might affect market share, for example. In the case of a migration to Windows 2000, the possible business benefits appear more tangible than those of some other upgrades. But you can't have benefits in a vacuum - it's important to see how they will affect your business in particular, and (preferably) its bottom line. By approaching the subject in this way, you end up with a more objective assessment of the benefits of upgrading, and one that is more likely to convince the people holding the purse-strings.
John Whitfield, IT services director with Softlab, says that when advising clients on their upgrade options the firm makes a point of considering overall business strategy. "Identifying the right timescale depends very much on what else you are planning to do. If you're a bricks-and-mortar enterprise planning to establish a Web presence in three months, you probably won't want to base that on Windows 2000 in the first instance, both because of the time it will take to implement Windows 2000 and because of the need for high availability."
Many organisations will seek outside advice to help them fill in the return on investment (ROI) figures on their business case. Larger enterprises in particular will find plenty of people raring to do this job, but it is important to understand the agenda of any company that might be hoping to provide you with migration services afterwards. Advice from independent consultancy firms can be valuable, as can the research of analysts like Gartner. But Whitfield warns, "US-based metrics can be misleading when applied to Europe. The costs of licences, labour and tin are all different, and so is the whole IT landscape, including the penetration of different products." The experiences of other user companies are obviously an invaluable resource, though inevitably an earlier adopter of anything will find reference sites thin on the ground.
Whitfield has another important piece of advice for those building and evaluating business cases for operating system upgrades. "Any ROI that's based on a period of more than two years will not be realised, because you can bet your bottom dollar that in less time than that the IT department will be back and wanting to do the next thing."
A business case for a migration is a volatile thing. It may not add up this month, but in three months time it may. The best advice seems to be to define the conditions under which you will migrate, estimate when they will be met, and then keep checking that your assumptions are correct.
Obviously, the reliability of a new product is something that will be watched for and, in the case of Microsoft operating systems, it is often suggested that users would do well to wait for the first (or even the third) service pack to appear. Another aspect to monitor is the availability of complementary tools and utilities. Whitfield warns, "When an operating environment is first introduced, some of the management and diagnostic tools essential for managing total cost of ownership won't be available, and things like printer drivers may be unavailable or in beta."
While you're waiting, you can initiate preliminary work that will allow you to move off quickly on the green light. That's especially pertinent to Windows 2000, for which a significant amount of preparation may be needed, according to Richard Moseley. He is managing director of FastLane UK, part of Canadian-owned FastLane Technologies, a directory management specialist that is supplying tools and services to help Shell International deploy Windows 2000 Server and Active Directory to 60,000 users in more than 180 countries.
Moseley says, "The planning phase of a Windows 2000 migration is likely to represent at least half of the project. If a largish organisation is planning to migrate next year, it should start planning now." Moseley adds that if you're on NT4, a rationalisation that is an important first step. "Many organisations have expanded their NT4 environments departmentally, and will need to consolidate what they have before migrating to Windows 2000."
Another important area for planning is directory content. Olivier Thierry, vice president at NetIQ, thinks this, rather than technology, is the biggest area of risk for a Windows 2000 migration. "Well before you implement anything physically, you need to think about what the directory structure will look like, and that's a non-trivial task, requiring you to describe a three-dimensional organisation in terms of a 2D directory architecture.
"It can involve a lot of politics and challenging business discussions, and it may take several iterations to get it right. Then you need to think about how you will maintain the data. If, for example, human resources is going to maintain an important field like social security number, what safeguards are you going to put in place to make sure that they do it correctly? It's never too soon to start thinking about all that."
For those that do decide on an early migration, planning a staged approach may be attractive, since it can limit risk and allow benefits to be confirmed before too much money and effort is spent. One such approach is illustrated by Memec. Another approach is suggested by Robert Drew, UK country manager with ON Technology. "You could, for example, gradually move all your desktops across to Windows 2000 and get the benefits like individual productivity improvements, then move the servers later."
ON sells deployment aids for Windows 2000 and Drew argues that identifying the right tools to tackle the migration in-house allows you to timetable the job to suit your company rather than someone else's. "If you hand the job to external consultants, they may be pushing you to do it as fast as possible because they 'can't let the resource go', and later it may be like Y2K, where there came a time when you couldn't find anyone free to do your work."
Ron Halversen is director of technology with Altiris, another company offering migration tools, in this case to "transplant the personality" of a PC from one operating system to another. He points out, "Tools can not only reduce the time lost by IT technicians during an upgrade, but can also minimise the down-time for end-users. If you're not careful they can spend a week recreating their cookies, wallpaper and so on." He adds that investigating the tools market can alter the look of your business case for the migration, because of the cost savings that automation can bring.
Planning how you're going to tackle the migration, and what tools and/or outside resources you're going to use, can put you in a good position when you decide it's time to jump. The fact has to be faced that there's never going to be a really ideal moment to migrate - other things always need doing but the evil hour can only be put off so long. As Thierry puts it, "Sooner or later, you're going to have to change the wheel on the bicycle while you're riding it."
Guest editor's view
In putting together a roadmap for migration, it's important to take into account the cost patterns associated with not upgrading. For example, where business partners upgrade ahead of you, there may be incompatibilities between infrastructures or communications that will begin to cause you extra work. Over time, points out Computer Weekly guest editor Peter Mansbridge, the cost of not upgrading are likely to increase, while those of upgrading will, with any luck, decrease as bugs get ironed out of the new product and the relevant skills become more plentiful. Anticipating and monitoring these patterns may help you to identify the point at which it becomes counterproductive not to upgrade.
In a wired world, however, the impetus to upgrade can be hard for an IT manager to control. Mansbridge illustrates this effect with reference to Microsoft Office. "You get to a point where users are getting e-mail attachments, or downloading documents from the Internet, and finding that they can't open them with the current version of the application. That causes delays and difficulties that translate to costs."
The manager then has the option of upgrading people selectively as needed - but that itself costs money since you are having to support more than one version, and that is likely to precipitate a domino effect as a result of which the whole company ends up upgrading. The alternative is to take the bull by the horns and upgrade everyone. "Either way, an apparently trivial upgrade can end up costing a company £250,000 in licence fees, and when the managing director says 'what's the payback?' it's difficult to come up with a good answer. The real winners are Microsoft and Intel."
Why migrate to a new version sooner:
- Because my business needs features only available in the latest version (eg we want to use Windows 2000's Active Directory)
- Because my current technology can't cope with an increased workload/more complex demands that have arisen since it was implemented
- To take advantage of new versions of other products (the software house we bought our ERP system from has stopped enhancing the version that runs on our current operating system)
- Because we're implementing a new application/merging with another company and it seems like a good opportunity
- Because ours is a leading-edge business and we need to be seen to be using the latest products ourselves
- For compatibility with suppliers, customers or partners (eg where version of product determines the format in which documents can be exchanged)
- Because the latest version has lower running costs
- To keep IT staff interested and aid retention.
Why migrate to a new version later:
- To defer expenditure on new licences and retraining
- To avoid tying up IT resources that are needed elsewhere
- Because the applications or tools you want to run aren't yet available for the new operating environment
- To avoid disrupting business activities
- To avoid the need to upgrade other system elements (a new operating system may require more powerful hardware)
- Because you'd rather wait until the new product is proven
- Because you need more time to plan the migration
- Because you are managing fine with the old one and can't see any business benefit from migrating at the moment.
Case study: Memec/ON Technology sees Merit in Windows 2000
Memec, the world's third largest distributor of semiconductors, has embarked on a staged Windows 2000 implementation. Rather than start by upgrading existing systems, the company has opted to make its first Windows 2000 roll-out that of a brand new system, a managed server infrastructure called Merit, which will support users of desktops, laptops and PDAs across Europe.
IT director Richard Gifford says, "If we were to implement this on NT4 we would inevitably be faced with an upgrade later, because a time will come when we need to be on the latest operating system to ensure we can get support. Although we could perhaps have saved costs now by sticking with NT4, our long-term costs would have been higher."
This initial project will be carefully evaluated as an aid to planning how and when to migrate other NT4-based systems, including Memec's SAP system.
Gifford admits there are certain risks attached to running a new system in a new operating environment. "Data General has helped us to manage the risks by configuring the system so that we can fall back to NT4 domain controllers should there be a problem with Windows 2000."
But so far, things are going well: "Putting Windows 2000 on laptops, especially, has dramatically decreased our costs of ownership," Gifford says.