Fog Creek Software
Discussion Board




To upgrade or not to upgrade ...

Like most companies we suffer from the constant upgrade cycle foisted upon us by vendors.  Given that our systems are not going to be rewritten to take advantage of any new product functionality, these upgrades benefit nobody but the vendors.

For example, we currently have a financial system written in Powerbuilder 6.5.1 and Pro IV running on Oracle 7.x 
It has all the functionality we need, there are no scalability problems with the system, and capacity should be sufficient for another 3 years minimim.  All the software is "obsolete" and unsupported, or minimally supported, by the vendors.

It will cost us $1million+ to upgrade to current versions of Powerbuilder, Pro IV and Oracle, for which we receive no business benefit what-so-ever.

Why should we upgrade, and what are the risks of not upgrading?

James Thorpe
Friday, August 08, 2003

If it ain't broke, don't fix it - why only three years? Use it so long as it works and fulfills your needs.

The risk, of course, is the difficulty in finding programmers to work on the system as time goes on. Oracle 7.3 was a tricky beast - tail end of the old RDBMS regime (the last version before MS put a burr under their saddle and really challenged them on the UI standpoint)

What you need to do is draw out a roadmap - plan out the next five years of development. You need to plot past growth and make some educated guesses on future growth vs. application loading.

Make a feature wishlist - is there anything you can't implement on the current system due to the technology? Is it indispensible to your business?

Is there code maintenance going on currently? How much do your developers cost? Are they likely to stay around?

Can you gradually refactor the system? Build in parallel, implement modules that work against the old database but can be moved to the new one; set up a parallel data store and implement new features there, linked to the old data until you port, etc...

Takes a *lot* of careful planning.

Finally, when you do port, don't get fixated on calendar dates. Try to manage cost, but you cannot manage the calendar.

Philo

Philo
Friday, August 08, 2003

There is no universal answer to "when to upgrade". No, "if it ain't broke ..." is not it either.
Not upgrading saves you in the short term obviously, since you avoid all the costs. However, in most cases upgrading becomes more expensive the longer you postpone it. I am not talking about missing the "special low cost upgrade licence" window for the software. More importantly the skills nescessary for a successfull transfer form the old system will become harder to find and more expensive over time.
Their is always a sweetspot somewhere in between holding out to long and unnescesarily jumping to early. Where that lies differs from case to case.

Just me (Sir to you)
Friday, August 08, 2003

Jim, you ask smart questions.  Common sense is so rare these days....

You make 1 case for upgrading b/c the software is unsupported.  Well, upgrading to the new Powerbuider (Does that joke still exist?) doesn't rectify that.  Sybase will be gone soon enough..

So you have answered your own questions.  Upgrading now would simply be bored programmers looking to amuse themselves, and those times are OVER.

What you should be doing is to plan for when your current system doesnt MEET YOUR NEEDS, in 3 years. 

Bella
Friday, August 08, 2003

Hi, my team developed an EAI billing system for a telco (10M subscribers) in the US, which completely replaced their old billing software and improved their business processes. The whole work, from design to production, was done in 2 years. The telco reported 1 year of ROI.

I'm not a big company, we not cheap, and we don't use PowerBuilder.
But we have a very thorough working knowledge of the technology and may do the job. To start work with us, please submit a Project Planning form on web site with your project information.

Evgeny /Javadesk/
Saturday, August 09, 2003

Guys,

Thanks for your reponse.  The example is only that - an example.  We have numerous systems in the same boat. My goal is to put together some sort of risk assessment framework that allows us to defer upgrading as long as possible, and bite the upgrade bullet when the risk gets too high.

Hence the question about the risk of not upgrading

James.

James Thorpe
Sunday, August 10, 2003

*  Recent Topics

*  Fog Creek Home