Top White Papers
Editor's Note: Speaking of MigrationApr 29, 2005, 23:30 (8 Talkback[s])
(Other stories by Brian Proffitt)
By Brian Proffitt
So, in June, I have this speaking gig at a regional tech show here in Indianapolis. Not a lot of travel, obviously, but I like public speaking, and am always thrilled to have a chance to promote Linux in person. Unlike a column where I just toss something out there and hope I am understood, being in front of an audience gives you that immediate feedback that can lead to a meaningful discussion.
The topic upon which I have been asked to speak is Migrating Legacy Applications to Linux, which is something I think I can address given my experience as a configuration manager many moons ago. Actually, the original title proposed to me was "Replacing Legacy Applications with Linux," which, if you think it through, does not reflect the program organizer's understanding of Linux very well. I already schooled them on the new title, and I hope to teach them more.
Since I got back from Canada, I have been doing some research on the topic and have found some pretty good articles out there on the Web that speak to migration. With a few minor variations, these pieces all draw up pretty much the same basic migration plan. In the spirit of open source, I'll let you see what I've found thus far. To save time, I'm skipping over the part where I talk about the history of Linux and the obvious advantages (cost, security, control, absolute freedom from naughty monopolies, etc.).
0) Know Thyself
Unless you are a home office or small business who knows exactly how many computers you have and what operating system and applications are running on said systems, you will likely need to know what is running in your company.
Software and hardware inventories may seem like a pain in the butt, but in my experience, no matter what you think you know is in your company's computers, you are very likely wrong. Over and over I hear tales of people bringing software in from home because "they know how to use it better," or even CIOs finding out they have been running Linux for years in their infrastructure and didn't even know it.
Performing a formal inventory will not only greatly assist the IT department in getting a handle on day-to-day operations, it will also help you in deciding just exactly how you are going to migrate to Linux.
1) Start on the Outside and Work In
This, without a doubt, is the most common attribute of all the migration plans I have seen so far. This includes the end results of these plans, which you would think would be "enjoy your favorite beverage while working in a complete Linux-driven oranization." Not so, as the end results vary wildly.
Regardless of the end result, the starting point is always the same: find some out of the way server, such as a file, print, or non-mission critical Web server and plunk Linux down on it. Monitor the results, and if satisfactory, repeat as desired.
Clearly, this is not rocket science. And even the most jaded analyst will tell you that Linux in this arena is perfectly safe. Unfortunately, these jaded analysts will also tell you that here is where Linux should stay. Sure, pull the other one.
2) Set Your Destination
You might wonder why this step is step 2 and not step 1. After all, shouldn't you identify your destination before making any changes? In theory, yes. In practice, let's be real. Once you have a handle on your company's systems, it should be simple to quickly locate infrastructure servers that can switch over to Linux without much fuss. You might as well start saving money as fast as you can.
This is not just me talking. Red Hat's Michael Tiemann mentions this as part of his open source "triple play" migration strategy: use the savings from one stage of deployment to help fund the next stage. It's a good idea, so I am shamelessly using it, with attribution so Tiemann doesn't beat me up.
Flush with initial TCO savings, you can now start figuring out what can go next. Here is where things get a little varied. Some migration plans, which have a total client-server Linux environment in mind, will recommend you start finding desktop users in the organization that can use Linux on the workstation right way. While this is a good recomendation, to me this runs parallel to deploying Linux apps in the server environment. After all, depending on the apps you migrate and your platform demographics, you might not even need Linux desktops to use them.
For instance, if you have an all Intel-based shop, a big development team, and a lot of home-grown apps, then porting server and desktop apps to native Linux versions might be economically and productively feasible. But if you have a lot of vendor-written apps that have no Linux versions, then you might have to migrate to a completely different set of applications (.NET to LAMP, for instance) on the server side to get to Linux, and then switch your Windows clients to a Web-based interface to get at the servers.
There are so many factors that go into this decision, I could spend weeks covering them all. Applications, platforms, costs, and human resources will all contribute to how you want to migrate. In the end, there are essentially three primary routes you will take to your final destination:
It is important to note that none of these plans have to stand alone. You could, for example, web-enable apps now on your way to a native Linux port down the line. Or migrate some clients to Linux and leave others on Windows indefinitely. It's all up to you.
3) Plan Your Journey
When you have identified what servers and clients you will want to migrate, now you have to plan how to get there. Initially, this seems like a straightforward "which distro?" decision, but there's more to it.
In Linux, all distros are free, ultimately, because you can get the source code and compile it. If you have the time and the talent, you can roll out Linux boxes to your heart's content and not pay a dime.
But, in reality, many companies don't have the time or the talent (though, I suspect, this last is steadily changing), so they need support from the distro provider. How much support will dictate what distro you need. Got two kernel developers and a member of the Gentoo team in your shop? Please, feel free to rock on Gentoo, Slackware, or any other non-commercial distro and bask in the glory of your own personal geek domain.
If, on the other hand, you have some working knowledge of UNIX/Linux, but not a great deal, you might feel more comfortable running Linspire or Xandros on the desktops and maybe Debian or Progeny Linux on the back end. That way you get ease-of-use, and support when you need it.
Or, for those of you who don't want to be bothered, sign up with Novell, Red Hat, or Mandriva or a third-party vendor like IBM or Sun (at least, while Sun's still selling Linux). You will pay for the support, but not as much as you would to Microsoft.
This, like all stages in your plan, is going to take some honest self-assessment. How much are you willing to spend? How good is your staff? If you do use a major commercial distro, there are various levels of support, so be aware of what you need.
One caveat: if you do go with a third party like Big Blue, make sure you know exactly what you are getting. While interoperability is not the scary bugaboo that analysts make it out to be, it does help to make sure all of your Linux distros (if you get more than one) will play nicely together. For me, it's pick one distro and stick with it. I don't buy into interoperability concerns, but from an admin and package management persepective, it will just make everyone's lives much easier.
4) Stick to the Plan...
...But be ready to forge a new path. Stuff, as we know, happens. Best laid plans, yadda yadda... Something will likely make your migration plan change somewhere in mid-stride, such as discovering that someone in accounting as been using an Excel spreadsheet as an ad hoc generator of payroll information for the last five years, and you missed it on the inventory. (But it got found the first time the pay data was compiled. Trust me, it's a true story.)
The best way I have found to deal with these kinds of surprises is make your implementation in discrete stages. Test, implement, run, move on. Those of you with in-house development shops will know what I mean. For the rest of you that are not as IT-focused, this simply means test one stage of your migration, then move it to a production (live) environment. Run it for a while to make sure all is well (having the old system on standby just in case). Then move on to the next phase.
Making small moves means you can keep better track of what's happening. If something does go wrong, you will have only brought down one to a handful of processes--not bring the entire company's computations to a screeching halt.
Those are the four steps I came up with, which I think cover the basics for any migration of this type. I have a few Linux-specific tips, though, that should be mentioned:
And that, I think, is the core of my presentation. Minus the smashed watermelons, of course. Hopefully it will be the start of some productive dialogues.
0 Talkback[s] (click to add your comment)