Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

We are starting a new project with a new customer.

We have a legacy application circa 1997 that we are planning on using to satisfy the customer's business requirements.

I have been on the fence as to whether this is really the right course both for our company, and for the customer.

I don't want to rewrite the app for no reason, but I feel that this older technology MFC, VC6 - has outlived its usefulness.

If I am honest with myself - I don't want to spend any more of my career on the legacy app either.

To that end, I have justified to myself that I should present to management a plan to develop a new, fresh solution based on current methodologies.

1) Am I wrong for doing thinking this is a good idea. 2) If not - how can I sell it to the business. There are definite advantages from the ongoing support perspective for the customer (more people with skill-sets in newer technologies - which in this case would probably be .NET with an XML or Lua based configuration)

I'll be happy to answer any follow-on questions to clarify my intent.

share|improve this question

closed as primarily opinion-based by durron597, GlenH7, MichaelT, Snowman, gnat Aug 19 at 19:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

There may be a third alternative - stick to MFC, but not to VC6. Porting it to VS 2015 will most probably be much cheaper than rewriting the whole application from scratch in a different language. Did you consider this? –  Doc Brown Aug 19 at 11:26

5 Answers 5

up vote 3 down vote accepted

Any project always has a number of possibilities which you have to decide between. Generally, companies are interested in mitigating the risk of a project (as this will determine how much money they are going to make in the long term).

  • By using "newer" technologies you may reduce risk in that generally newer technologies (newer than 1997 anyway!) tend to be better documented and supported in terms of their internet presence (e.g. Stackoverflow).
  • Your staff may be motivated by taking on a new and exciting project with good prospects of learning something interesting. (Who doesn't like something new?)
  • Customers tend to be impressed by "bling" as much as anyone else. If you can impress the customer while remaining under budget you will increase the prospect of repeat work.
  • Is there the possibility of reselling the new software to other customers

Conversely, if your legacy project has a good track record, fulfills the requirement and can be maintained by existing staff with no extra training, this may be a big hurdle to overcome. You may run into supportability issues:

  • Will this software run on the customer's environment?
  • Is there a problem hiring staff with the skills to maintain / develop this software? (Could be expensive)
  • "Technical debt" of legacy systems is also a risk - how easy is it to change, maintain and test the existing product?

You have to weigh up the pros and cons. As always, it will tend to be a management decision, but they will generally be swayed by monetary arguments.

share|improve this answer

Firstly you need to remove your prejudices from the process. I know it is so tempting to move on to new stuff, but you are not providing the best solution for the customer you could end up in a lot of trouble.

I would recommend you enumerate the risks of the legacy solution. Investigate in detail if the tools and the runtimes will still be supported by Microsoft in the future and check that they can run on your customer's platform. Also consider difficulties in maintenance if changes are needed to a code base like this. E.g. can you still get the tools, are the skills available in your company or the wider market.

If, in doing this, you uncover risks (and I suspect you will) you need to present those to the management (and maybe the customer), along with your plans for rebuilding in .Net / Lua. You should be fair and mention risks with your approach too, to allow for a fair comparison of the 2 approaches. And to get maximum leverage I would strongly suggest doing some sort of prototype or PoC in the new tech before you present your findings.

share|improve this answer

The three considerations you'll need to sell your management on is:

1) Is it cheaper?
2) Will it cost less money?
3) What will be least expensive?

It's kinda like real estate that way. You know, location location location? Just like that.

Any developer-centric notions of "betterness" are at way down the list of concerns for most managers and clients.

share|improve this answer

1) If the legacy application can "out of the box" meet all the customers requirements then starting over really isn't an option.

2) If the legacy application does not and you feel it would be cheaper to start fresh and still meet all those requirements then you have your answer. I can tell you this most likely will not be case for the simple fact you have the added task of testing to make sure the new application does everything that the legacy application can do ( or everything the customer wants it to do ).

It will come down to the fact the legacy application has been working for 13 years vs 0 days on this application that has not proven itself and likely will take at least 2 releases to get all the "new" issues worked out.

share|improve this answer

Some additional questions:

1) Is the underlying technology of the legacy app still supported? Using completely unsupported tech tends to make management extremely nervous. 2) How hard is it to find skilled people in the legacy tech versus the new tech. 3) Are there features that the customer is looking for that do not exist or fit well with the legacy app (i.e. integration with enterprise services or social media)

Be realistic about the project though. If the legacy app does everything the customer wants then it might just be the best fit.

share|improve this answer
The legacy app will need to undergo substantial modifications to meet the customer requirements, however it does meet several of the requirements "out of the box" –  sylvanaar Apr 14 '11 at 14:07
In that case, you probably want to estimate how long it would take to do modify the existing app and estimate how long to rewrite it in the new tech. That will give you starter numbers to work with. From there list the pro's and con's of each option. Be honest and fair to both choices. Once you have a full list, create an executive Summary that lists the costs involved and the top 3-5 pro's and con's for each and present that. –  Dave Wise Apr 14 '11 at 14:15
You also may have a political issue in the mix. Since this is a new client, your own management may want to make as good of an impression as possible, which means hitting the feature set on time and under budget. –  Dave Wise Apr 14 '11 at 14:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.