South San Francisco company seeking an IT Practitioner with experience migrating servers from a Linux distribution running 2.4 kernel to a Linux distribution running 2.6 kernel.

Job Description:
Background: We are helping a client evaluate a migration from SUSE Enterprise 8 to Red Hat Enterprise Linux. We require assistance defining a migration plan and getting an idea of the cost in terms of man-hours for different phases of the migration plan.

This assessment will take place over the next week and will require 2-5 hours of your time. You may telecommute.

Pay: $150/hr+ depending on your experience and depth of knowledge

Requirements:
-Have migrated or managed a migration preferably from SUSE 8 to Red Hat Enterprise, but requirement is any distribution on Linux kernel 2.4 to Red Hat Enterprise.
-Migrated servers must have been in a live environment which ran database and mission-critical (e.g., ERP, CRM, Finance, etc…) workloads.
-Migration was in a hybrid environment running both Linux and Windows for client with 250-500 PCs.
-5 years of Linux and Unix experience. At least 2 of those years must be directly administering or managing Linux environments.

When submitting your qualifications, please also answer the following questions:
1. Do you have a go-live checklist? If so, please attach.
2. What were the factors that had the largest impact on schedule and budget of the migration?
3. What are the biggest risks in such a migration?

Um, once you have all the applicants' checklists (task steps?) with the key important items and biggest risk items denoted, why would you need to employ any one applicant?

This guy has no idea. 2-5 hours to plan a migration of how many servers and how many desktop users?

I work in a Bank. responsible for approx 1600 physical 'mission critical' servers. and thats not all of them either.

If you had any idea how much of a cheapskate you are being, you wouldn't have bothered advertising here.

People note: 'Scapegoat wanted'

On the other hand. I charge out at $4000USD per day plus expenses.

I'll give you the heads up. Migration takes more than 2-5 hours to plan, and takes more than a week post physical, to sort out production issues and bugs. Sometimes problems don't appear for months. I hope you have a contingency plan.

GOOD LUCK!!!

From the responses to our post, I gather I did not convey what we are looking for adequately. We are looking for someone who has previously done a migration between Linux distributions. We want to know what steps they took and what the costs and difficulties associated were, on a previous project. As far as planning the migration for our client, that is a separate piece of work which the applicant may be invited to work on. I agree that would obviously take longer than 2-5 hours. We are doing very preliminary research right now and are just looking to learn how other migrations went. I hope that clears things up.

-Amy

I guess you need to understand that people are paid large sums of money to take on a headache such as this. I don't think those who do migrations, be they project managers or engineers really would share their secrets for free. I know I certainly wouldnt, given it's taken me 15 years of hard work just to get myself this far.

If you really want to understand the difficulties involved, list all your applications, and what they run, then check what matches in the new distro.

be it SLES or RHEL ES, I think you will find that you will need at least 3 weeks rolling it in a staged test environment before moving it into production.

If they cant or don't have a lab, then you're pushing excrement uphill. make them get ALL the required hardware before you even consider planning the rollout. you need to take that into account.

for example: we rolled a new software app out. the dev cost 3mill and 18 months to get to prod testing (think of a migration being about half this time)
it then took another 2 mill to make it prod final (allow for ongoing support) and only a measly 1.2 mill in back end hardware.

I guess unless you can quantify the scope and give examples, noone is going to give you a detailed response, and thats why you hire people after an interview, and not over the internet )

I spotted the original post right after it went up, and chose to ignore it for obvious reasons. Since a few other people have responded, I'll throw my hat in the ring.

The complexity of the proposed activity is very high. The liklihood of it being accomplished without error or with only minimal error in a live environment is effectively zero. It will take a test lab, with the same hardware, and a considerable amount of time, to make it happen. If the test lab has similar but not identical hardware, then a test lab deployment won't guarantee success in the live deployment, though hopefully the "go live" problems won't be too serious.

Computers are the most complicated machines that humans have ever built. Can't treat 'em like toasters, though I understand that most people would like to do that. Migrations are hard. That is all there is to it; they are hard.

My 2 cents: First, I think it might be useful to point out that all LQ Job Market postings are vetted and approved by the site admin before they appear in this forum, and I think it's useful to keep that in mind when responding -- unlike the other LQ forums, it's not like people can just instantly create new threads in this forum. With that in mind, if you have a question about the job itself and/or the responsibilities that are involved, feel free to post your comment, but posting misc personal commentary about a job listing seems unnecessary. From my point of view, if you're interested in the work, by all means contact the OP, otherwise, it's on to the next thread.

Second, although I cannot speak for the OP, as I read the job posting, the company is in the preliminary stages of trying to hire a person who has the right experience and credentials to manage and oversee a significant Linux migration project, and therefore they are asking interested candidates to answer a few basic questions to determine if they are qualified. The questions being asked seem to be nothing more than the online equivalent of a phone interview, and assuming that a suitable candidate is found, I think the "2 to 5 hour" time estimate refers to a discussion about the migration plan, rather than how long it would take to actually perform the migration. As the original post says, time estimate refers to "the assessment ...." (italics added), not the start to end project timeline.

Again, I cannot and am not speaking for the OP, but I think it seems clear that the purpose of the job posting is simply to find people who could be qualified to be considered for the position. Presumably if a candidate was interested in the position, and the company felt he/she had the right background, then the next steps would be conducted offline, and would include more traditional phone or in-person interviews. That's just a guess, but that's how I'm reading it....

I think it's the "If so, please attach." that raised red flags for some of us. I think that is what triggered "share their secrets for free" in the following:
It certainly triggered similar thoughts for me.


BTW, J.W., thanks for the insight into how this particular forum is run.

The types of questions that we are hoping an ask an experienced individual will NOT be specific to our migration. We understand that every migration is different and attempting to address our individual case in a brief phone interview is not what we are looking for.

We are right now trying to figure out what makes a migration difficult, what applications are most difficult to migrate, what part of a migration takes the most time, what kind of training the migrators should have, etc. At this time we are only looking to hear about a specific migration that was performed in the past between different Linux distributions, or between different versions of a Linux distribution. Those of you who responded to the original post actually seem like you might be able to help with our research. From what we've found from our interviews so far, the conversation should actually only take about 30 minutes, but we are still prepared to offer $150+ DOE.

After evaluating general migration requirements and difficulties, our client will decide whether to proceed with a migration. At that point we will likely choose to hire someone full time to plan and perform our specific migration for an appropriate amount of money. Again, the $150+ that we are offering is just to talk about something you've already done, no new specific information required, and no confidential information expected. Please feel free to contact me if you are interested. Thank you.

Amy Buchen
abuchen@key-inc.com

Honestly, I don't think that any one application is more difficult than any other application, though which would cause the most grief would depend in a very detailed way on the exact version of the OS being migrated FROM and the exact version of the OS being migrated TO.

The devil, as they say, is in the details. There are lots and lots and lots of details; literally millions of details. Which details become variables again depends on the specifics of the migration.

I have found that it is often easiest to just do a complete new load of the new OS on new hardware (or on a lab system that mirrors the system(s) that actually are running and will be hosting the new OS), then just worry about migrating the key application data. In very many cases, this is the route that is quickest and most effective since usually application data is a very small subset of the total problem and doing a clean install is the best way to sidestep all the detail problems that appear when you try to upgrade. Further, most applications retain backward compatibility fairly well (so long as the application isn't Microsoft Access, that is) so moving the data is often no effort at all, or at most involves running a vendor-supplied tool on the data to upgrade it.

Now, if the new platform is radically different hardware, and there is no chance of binary compatibility between platforms, the complexity of the migration usually skyrockets. In this case, I generally prefer to do it in phases, with each phase validated and working before the next phase is undertaken. Thus, I might set up a lab and get the new client working with the existing server (which might require modifications to the server), then cut in the new clients a few at a time until the new clients had replaced the old clients on the existing network. Then, when I was satisfied with the performance of all of this, I would go to work on the server side to upgrade it. When my lab system demonstrated that the new server and new clients could work together, I would bring the new server online in parallel with the old server. The old server would remain live for awhile, with the new server undergoing testing in the live environment. Then, at a specific time, I would switch to the new server. If I had planned well, and if I was lucky, the users would never notice the move.

In fact, I did proceed exactly that way one time when upgrading one of the Air Force Logistics Command's major networks, but that was a looonng time ago.

By the way. I just gave you your roadmap for one kind of migration. Lacking details of what is required, I can't be more specific, though I would expect the specified migration to be a piece of cake (relatively).

Every migration is unique and depends on the apps and infrastructure that an org is running.

I think jiml8's post is as detailed as a post can be on this matter in a forum such as this one.

chiaz

You can talk to us on s7solutions.com and that's what we keep doing all day and all year long (from last 8+ years) but 2 to 5 hours for assessment is not a realistic one if I can speak from experience

Nikhil

Ah, I understand.

Keystone is only paying for the write up. The actual migration will be done by keystonecops.

End

Amy,
[ aka keystonestrategy ]

Why switch from Suse to RH?
both are "Enterprise Linux" and switching to a newer version of Suse is a far easier Migration, as well as being the same cost or less, for the distro.
[ ignoring the simple fact that Suse is based on RHEL ]

By staying with Suse to be running on the 2.6 kernel it is more an upgrade of the software than a major change, and the current live systems should be able to literally be upgraded with no alteration of configuration.
once the client is using the newst versions of the software, then it's a far simpler task to change distros, if they desire it.

~ crawling back into my hole to continue cross compiling linux from scratch on new multicore 64 bit system my current migration undertaking ~