Complete FAQ on Migration

To many of our readers the term migration may sound like away of life. After all, software programmers are known for their yen to migrateto distant lands in search of the greenback. Though the migration we’ll talkabout is of a different kind, there are many similarities between the two typesof migration. The fundamental requirement of all migrations is the movement fromone to another. The movement from one location to another for softwareprogrammers, and the movement from one machine to another of applications andusers. Here are answers to questions on the migration of the second type thatyou may have.

So, what is the migration you are talking about?

In a connected world, the server is at the core of thenetwork. Residing on the server are the network operating system, server-basedapplications like mail or work-flow applications, and, most importantly, useraccounts, profiles, and user data. Migration happens when you move the userinformation and their data to a newer machine, possibly changing the operatingsystem and the applications or both along the way.

But, wait a minute. Why should I migrate in the first place?

As more and more users get added to the system, the oldermachine may not be able to handle the load. In this case you have to moveeverything to a newer, more powerful machine. Along similar lines, operatingsystems and applications come out with newer versions that add newer featuresthat you may want to exploit. Or, there is the third scenario, when you may wantto altogether change your operating system or application. Under any of thesecircumstances, you will have to consider migrating your users to the new setup.

Is migration the only option?

Not really. You have the choice of upgrading. Upgradinghappens when you move from an older version of software (operating system orapplication) to a newer version, on the same machine. As we saw earlier,migration involves shifting to another machine.

Which is easier, upgrading or migrating?

Upgrading is definitely the easier of the two. The newerversion of the software will invariably be able to detect the presence of theolder version, and import user settings and data. So, an upgrade is a far easierprocess, unless you are upgrading from software that is many versions old and isno longer supported.

Then, why migrate?

Migration is the way out when you want to move from oneoperating system to another by a different vendor, or from one application toanother. In this case, particularly with the different operating system, youcould end up loosing all user settings and data if you were to install it overthe older one. So, you would have no choice but to install the operating systemyou are moving to on a different machine, and move users and their data across.Also, when you move from one application to another, you may want to do that ona new machine, to avoid any chance of loosing existing data. Normally, acombination of circumstances will lead you to decide to migrate your users to anew machine, like having an old machine with older software installed.

What all will change during migration?

Of the four components involved–machine, operating system,application, and user profiles and data–the machine always changes for theoperation to qualify as a migration. At the other extreme, user profiles,preferences and data should not change, or there will be chaos all around. Thatleaves us with the operating system and the application. Either or both canchange. It’s rare when only the operating system changes and the applicationremains old. This is partly because new versions of applications get releasedsimultaneously with new versions of operating systems. There is another scenariowhere only the machine changes and the operating system and the applicationremain the same. This will not qualify as full-fledged migration because toolslike Norton Ghost can simply copy the complete setup from one machine andduplicate it on to the other.

How risky is migration?

Migration is as risky as crossing a road. Done with due careand proper precautions, neither poses a problem. Done carelessly, both can havedisastrous consequences.

What precautions should I take before migrating my users?

First of all, back up all existing stuff–operating system,applications and data. Second, like the old timers say, RTMF (read the manualfirst). Any software vendor worth its user license agreement will publishdetailed instructions on how to upgrade from its own earlier versions, ormigrate from competing software. These tomes that are usually available at theirWebsites are often bulky. But reading through them, or through other referencebooks, can save you from enormous amounts of heartburn and wasted time, as wefound out at our cost while doing this story.

Is all the work in migration confined to the server?

By no means! If you are migrating across operating systems,you may have to change the network client software at the client machines sothat users can log in to the new setup. If you use login scripts, then they mayneed change. When you are migrating applications, then also the appropriateclient-end application may have to be installed.

How long will it take to complete a migration?

The answer to that one depends on how large a network you aremigrating, and how many users and applications you have on it. The process canget over in less than a day if you are migrating just one server. On the otherhand, if you are migrating all users on a global network, then you could wellhave a largish team working round the clock for a month or more.

What exactly are the steps involved in a migration?

First, take the precautions as described above. If you do nothave updated documentation of your network and server, then this is the lastopportunity you would have to create one. You need to document operating systemand application settings, IP addresses, user and group settings, includingrights and disk quotas, configuration information for peripherals like printers,etc. This information is very critical, particularly if you run into problemslater.

The next step is to carry out a test migration. Ideally, youshould do it on a machine other than the one on which you will do the finalmigration. You can use an old machine for this. You set up the operating systemand applications on this one exactly as you would on the new server. That is,you will apply the latest patches, and so on. Now you will start the migrationas if for real. Any problems you face will not lead to critical losses, and youcan afford to experiment and find out work-arounds. It will be a good idea todocument these as they happen, for use during the actual migration. Once thetest migration is complete, you will want to do a sample check on whethereverything has moved over as it should have. Once you have satisfied yourself ona successful test migration, it’s time to do the real thing. Once you completethe migration, check again to see if everything is okay. Now you are ready forinstalling the correct software at the clients, and completing the job. Finally,wait a couple of days before congratulating yourselves on a job well done. Minorhiccups are bound to occur.

Which should I migrate or upgrade–the operating system or theapplication?

In a network, you will normally undertake an upgrade or amigration only when there is a significant immediate benefit that accrues out ofit. In most cases, that will happen at the application level than at theoperating-system level. So, even if the newer operating system offers great newfeatures, if there are no applications that can take advantage of them, there isno reason to just migrate for the sake of the newer operating system. Sometimesthe operating system in itself does offer significant benefits, like when NT 4offered much more stability over NT 3.5. Or when NetWare 4.X offered thebenefits of the NDS over the bindery of NetWare 3.X. In such cases, it makessense to migrate just for the better operating system. But, interestingly, inthe case of NT, applications for NT 4 soon followed, and migration decisionswere back to application and operating system together. In short, it’s theapplication that drives migration or upgrade decisions on the network server. Onthe desktop, the considerations are different.

When do I pull the plug on the older machine?

Typically, you will have both the old and the new machinesrunning for some time, so in case there are problems with the newer setup, thenusers can switch back to the older one and continue with their work. Also, youcan use the old setup as a reference to troubleshoot the new one. Onceeverything has stabilized with the new setup, and everything is runningsmoothly, you can dismantle the old machine.

Is it worth all that effort?

That depends. Remember that the decision has little to dowith technology or the fact that your favorite software vendor has just releaseda new version. No network administrator or CIO worth his salt would decide tomigrate a huge network just for the thrill of it. The migration should yieldclear tangible benefits to the administrator or the user, if not both, likevastly improved usability or administerability or the ability to run vastlybetter applications.

Krishna Kumar