OS Migration

Walking the OS Migration Tightrope

Some steps and rules to keep in mind to prevent OS migration from being a major headache. by Graeme K. Le Roux

Changing the operating system of the servers on your network is not something you do without much planning.

In most cases you'll only do it if there's an overriding cost benefit, a business requirement to deploy a new application environment which is not supported under your existing OS, or you need to merge two dissimilar IT operations. Whatever the reasons, there are a few constants in the OS migration process.

Migration procedures

Firstly, you need to be very sure that the OS you're migrating to will actually do the job.

This sounds obvious, but it is not.

If, for example, you have a particular application which is written for a database engine that runs under both your current OS and the one you're migrating to, you cannot assume that every function which exists in one OS exists in the other, or that the functions which exist in both OSs work the same way on both of them.

The only way to be certain that all your applications will work under the new OS is to test them. You do this by buying or renting a suitable platform, installing your application environment, taking a copy of some or all your live data and then running a series of tests to simulate your normal operations. You will also need to test out your procedures for dealing with abnormal situations, such as disaster recovery procedures, etc.

The next problem is working out the mechanics of migrating your data files. If your data files are on a storage volume which is in an OS-specific format, then you have to move them off that volume so that you can reformat it for the new OS. After which you have to put the data back, which can be more of a problem than you think.

This is because you have to consider how quickly you can move your data. Chances are you will have a weekend to do the job at most, and you will still have to do your normal end-of-day/week processing. Then there is the question of what you move the data to—tape can have an OS-specific format, SANs based on iSCSI or fiber channel may or may not need to be reformatted.

The simplest solution is often to use an OS independent NAS solution. If your file formats are the same under both your source and target OSs, you can simply copy your data to the NAS volume, reformat your servers/hosts and restore your data. In fact, you may want to consider using NAS as your primary data store, as an online backup, or both.

Once you have figured out the mechanics of migrating your data, you have to work out the corresponding process for your application files—all the queries, reports, and other server-based processes that you have written in-house or had written for you.

Fortunately, the solution you used for your data files should work for your application files as well. The application engines—e.g. database engines—will have to be replaced with the versions appropriate to the new OS.

When you have ascertained that the proposed migration will work and the mechanics of moving your data and applications, you need to work out who the migration will affect, how it will affect them and how you can prepare them for the changes they will face.

Re-training

After you have changed your system's OS, you will have to re-train your operations personnel to work with the new OS.

However, the best training course in the world will not provide the sort of experience you want in your senior operations personnel, especially when you are doing something as complicated as an OS migration.

You will need to bring in contractors, who will be able to help test your applications under the new OS, to provide extra manpower during the migration, and to act as mentors/support to your re-trained operations staff, usually for a year. This is not going to be cheap, but it is necessary.

Whenever possible, you should confine the effects of migrating from one OS to another to the glass house rather than risking the effects of extending it to your general user population. This is because the process is easier to control in the glass house and it costs less.

It is also a good idea to use some volunteers during your testing process. This will give you a good idea of what the practical effects of the migration will be on your general user population, and thus what the effects will cost in terms of required user training, extra support resources and lost productivity. Remember to provide for the unexpected in your project budget too.

Unix and Windows Clients

One of the more difficult issues associated with mixing OSs in a single system is dealing with Windows clients.

In fact, this problem has spawned an industry that supplied add-on software to make Windows interact intelligently with Unix hosts, starting with basic TCP/IP and telnet implementations and even including NFS and RPC add-ins.

Few of these add-on products exist today because both Windows and Unix—especially Linux—have evolved to be more compatible with each other. Windows defaults to installing a TCP/IP suite and comes with a Java capable browser. Samba provides SMB/ CIFS support on most Unix platforms. Windows supports FTP out of the box, and both Windows and Unix platforms can use each other's printers.

Add-ons are still required, when you want to have a Windows server support Unix clients, since Windows tends to assume that Unix is a legacy platform and that all clients in a network will be Windows platforms.

Making Migration Easier

Even if you are not planning an OS migration soon, you can make any future OS migration somewhat less of a drama by keeping a few simple design rules in mind whenever you upgrade or expand (or shrink) your network:

* Keep your network transmission system simple. Use fiber for vertical (or long) runs, single drop copper for horizontal runs and switches whenever you have to join the two. If you use quality copper and fiber, this will allow you to add new services without having to adjust server or client configurations to account for wild variations in latency and available bandwidth. This approach allows you to upgrade the QoS of particular paths in the network as required, and segment groups of ports from your switches. This means that you don't have to move a complex network configuration to your new OS platform.

* Standardize on the TCP/IP protocol suite. All OS platforms support TCP/IP protocols and basic applications such as DNS and DHCP. Making sure that your new OS platform supports your existing network protocols will obviously makes migration a lot easier.

* Try to use standard Internet applications such as DNS, DHCP, SMTP, Web servers and clients wherever possible, rather than proprietary equivalents. You can be certain that any new OS will support existing standard services, but the same can't be said for proprietary services.

* Wherever possible, separate data storage and backup from data processing. For example, store files in a NAS box which is OS and client independent rather than on a specific type of server which may or may not support any new OS platform. Then when you migrate your application environment to a new OS platform you should not have to worry about moving data.

* Try to limit the number of different processing platforms in your network. If you have databases for example, try to use just one type of database engine running on one type of OS. This cuts your testing and support costs, since if you are mixing five different SQL engines in your network you have to test all of them in the new environment or port code and data from all of them to any new environment. This is a much more expensive task than testing a new version of an SQL engine you are already using.

All these rules can be summed up as keeping your system simple, and can help prevent any IT project from turning into a nightmare.

This article first appeared in Network Computing Asia