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
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
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
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
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:
Native Linux Ports: From a performance
standpoint, clearly the best option. You get stability, security,
and a much easier-to-manage platform in your organization. Could be
some work getting here, though, depending on your
Web-enabled: Linux on the back-end, intranet
on the front-end. Here, you employee's desktops can run anything
they like and you still maintain productivity and save money on the
server side. The bad news is, you still have to deal with Blue
Screens of Death.
Emulate/Virtualize: You can do this on either
the client or server side, using emulation tehnology such as WINE
or virtualization apps like Xen or VMWare to provide your employees
exactly what you need. In my experience, though, a lot of hardware
resources are needed, and you still have to deal with Windows
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:
Know what you're getting into: "Linux is
viral!" "The GPL is communist!" "Penguins will come and eat your
young!" Yeah, yeah, we've heard it all before. If you have any
reservations about Linux, Free, or Open software, do some
research--from a variety of sources. Ask around, get your concerns
answered. Most of what gets spread about Linux is dated hearsay or
deliberate spin. Linux, like any OS, has its own limitations and
strengths. Find out what they really are.
Stick to standards: This is my personal
mantra. Standards will set you free. The more standards you follow,
the less likely you'll get stuck in the morass of a proprietary
Build your Linux mojo: Once you get started,
encourage your IT staff to take initiatives in Free or Open Source
software. Once you give back to the technology, a lot of people
will be willing to give to you when the time comes.
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.
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.