Traditionally, your software modernization choices are as follows:

1. Rewrite the existing functionality using new technology.
2. Throw away the old and build new custom software.
3. Adopt 3rd party packaged software, like Enterprise Applications: SAP.

Let's analyze these options..

Option-1: REWRITE THE EXISTING FUNCTIONALITY USING NEW TECHNOLOGY.

The problems here are those of time and cost.

UNBEARABLE TIME

The Gartner Group estimates that the ultimate productivity of a manual code conversion effort is no more than 107 lines of COBOL code per man day. That means a moderate 1 million line application will take 9,345 man days to convert; equivalent to 39 man years. So a 20 person team would have to work a full two years to accomplish the conversion.

Keep in mind the principle of Mythical Man-Month; because this number is not as scalable as it appears. Deploying 80 programmers would probably not complete the work in 6 months; and 160 programmers would certainly not complete the job in 3 months.

HUMUNGOUS COST

Even if we offshore this work to India, this job will cost approximately $3 million.

INTRODUCTION OF NEW BUGS

Even if twenty veritable geniuses were assigned to the project, the rewritten code would have bugs - that is a given.

Option-2: THROW AWAY THE OLD AND BUILD NEW CUSTOM SOFTWARE

Some of the same drawbacks as Option-1 remains. The cost and time involved in a fresh requirements analysis, functional specifications, software architecture, technical specs, coding, testing and deployment would be gargantuan.

Additionally, we would be throwing away the baby with the bath water.

THROWING THE BABY AWAY WITH THE BATH WATER?

Legacy software is usually good. That's why almost every Fortune 100 company still runs tons of legacy software. Right?

Right. Legacy usually does mean "success". So many companies have legacy software because these old software do the job well. Because core business processes -- deep inside a company -- are not as prone to change as the more "visible" parts of a company. Existing software is also time-tested and usually free of major bugs. This legacy (goodness) must be cherished and preserved.

In each of these cases, all the goodness developed through the years is lost; a good company asset is trashed; an ideal example of throwing the baby away with the bath water.

Option-3: ADOPT SUITABLE 3RD PARTY PACKAGES SOLUTION

Typically, where business applications are concerned, the choice here veers towards an established Enterprise Software like SAP and Oracle Apps. These software have indeed become very sophisticated and provide a very rich set of business functionality out of the box.

But when we look at the implementation history of Enterprise Apps, we see a almost two decades of evidence pointing towards serious cost and time overruns. Why do these projects take so long to complete?

Because these software are most powerful in providing you with industry "best practices" out of the box. But "best practices" is not what makes a successful company successful; their success formula lies in the things they do a little (or a lot) differently from others: their "differentiating factors". This is the "gap" that ERP Functional Consultants determine, and which the ERP Technical Consultants then try to bridge by developing custom code using ABAP, NetWeaver. XI, Java and other tools. But that gap covering exercise is a traditional software development lifecycle that fights the traditional challenges of the Business-IT Divide, and provide results similar to what traditional IT provides: time and cost overrun.

If a 3rd party software covers only 90% or less of your required, this strategy is very unlikely to provide satisfying results.

A much better method is Automated Transformation to new technology.