HP3000-L Archives

March 2002, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Alan Yeo <[log in to unmask]>
Reply To:
Date:
Fri, 8 Mar 2002 02:01:34 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (121 lines)
Gavin's comments just about hit the nail on the head, and should be well
heeded by many. It summaries neatly most of the points that many of us
have been making over the last 4 months. It should perhaps be made
required reading for anyone who mutters the phrase "we are going to
migrate to another platform"

I will just reinforce a couple of points, 1) the tools will get better
and cheaper, and some that are only dreams at the moment will be a
reality. Plus I don't think all the potential options (other than
migration)that 3000 Users will have are yet quantified.
2) An additional option is to do as much as you can whilst still on the
HP3000 to remove replace 3000 specific operations, functions and
software, so that later migration becomes more feasible. However to do
this you still need to do the planing bit.

Alan (Can I steal some of this Gavin) Yeo

In article <[log in to unmask]>, Gavin Scott
<[log in to unmask]> writes
>David writes:
>>     For those of you out there with development staffs, please share your
>> thoughts regarding the pros/cons of aggressively moving forward with
>> migration.
>
>My personal advice would be "plan now, execute later", and in the interval
>be aware of things you are doing that you might be able to do slightly
>differently so as to minimize your dependence on the 3000 if you actually
>get to the "execute" phase.
>
>Planning early is important as you have to recognize the true scope and
>impact of the loss of your HP 3000 systems to your business.  If you're
>going to get rid of your 3000s, this is not going to be something that you,
>as an IT manager, are going to be able to just slip in without "bothering"
>upper management and your user community.  There are going to be *no* easy
>answers, *no* "magic" migration tools.  The costs are going to be very high,
>and not just in terms of money.  Chances are you're going to have to
>re-train all your users on whatever the replacement system is (even if it's
>a migration of the current system) and they probably aren't going to be
>happy about "you" taking away their cherished (i.e. they know how to use
>them and are comfortable with them) applications.
>
>Planning now means understanding in detail what you use the 3000 for,
>including a detailed inventory of not only the application systems and
>surrounding support systems, but all of the *interfaces* between these
>systems and the rest of your organization and other organizations.  Today's
>systems talk to a lot more other systems (and PC users with ODBC, etc.) than
>used to be the case.  If you've been through a migration before (say ten
>years ago) you need to be prepared for this one to be much harder, because
>of the inter-system interfaces that exist today.  These interfaces may all
>have to change at once, limiting the ability to do a slow "phased"
>migration.
>
>Keep in mind the three basic options for *each* application you have on the
>3000:
>
>1) Replace it with something new (off the shelf product or new development).
>
>2) Migrate the code to another platform.
>
>3) Leave it on MPE indefinitely.
>
>Don't think that you have to chose only one of these options for all your
>applications!  You might well chose to "replace" your core business
>applications (accounting, etc.) while "migrating" those key (probably
>customized) applications that give your business an "edge" over the
>competition, and there may still be important applications that make more
>sense to leave on MPE than to migrate or replace them.  I think many
>customers will end up using a combination of two or even all three of the
>above options.
>
>By planning now but executing later, you have the opportunity to sit back
>and watch things develop.  It's still very early after the HP announcement,
>and people are still scrambling to figure out what the future will actually
>look like.  Do you want to be the first customer for an unproven "migration"
>product for example?
>
>While many businesses will take *years* to implement plans to get off the
>3000, there's still time to wait and see how things change in the next year
>or so, especially if you've done the up-front work to make sure you
>understand the scope of what you'll eventually have to do.
>
>I think over the next year we'll see some movement in the relative costs of
>each of the above noted transition options.  We'll start to find out just
>how easy it is to "migrate" various kinds of applications and which
>migration service companies are the best.
>
>You can start investigating potential off-the-shelf replacements for some or
>all of your applications today, giving you more knowledge with which to make
>your future decisions, and shortening any eventual selection process.
>
>You can wait and see how the "operating system wars" develop.  How will,
>say, HP-UX look relative to Windows and Linux 6, 12, or 18 months from now?
>
>And option #3 of leaving your applications on MPE Forever can only improve
>over time.  Things like the OpenMPE movement and the possibilities of
>solving the "hardware problem" with an HP 3000 emulator are unknowns today,
>but may start to take shape in the future.
>
>And of course everything will get better/faster/cheaper the longer you wait.
>
>The only downside I can see to waiting is if you end up choosing a
>labor-intensive operation like source code migration and by the time you're
>ready to do it there are no resources left to hire to help you get it done.
>Fortunately, unlike Y2K, the deadline for transitioning away from the 3000
>is relatively flexible, and for quite a number of people there is no
>deadline as they're just going to stay on MPE no matter what happens.
>
>G.
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

Alan Yeo
[log in to unmask]    Just because you're paranoid
Phone +44 1684 291710   it doesn't mean someone isn't!.
Fax   +44 1684 291712

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2