Making a stale MFC banking application nimble so that it can be migrated to cloud

Question

0.00/5 (No votes)

See more:

Hi,

We have a huge banking application which has different executables(core executbales are the same but every client has some specific requirements so some changes) and hardware for each client, as the clients are increasing the required hardware cost has increased to around 75% of the total cost.

The problem is this application is built using VC++,C++ and Oracle 9i( with around 4-5 million lines of code )

How do we migrate it to a a nible application so that it can be migrated to cloud eventually.

I was thinking of migrating the application to a webserver using java, java stored procedures, oracle and ofcourse a thin client, but again this doesnt look very promising

Please advice

note - main focus is on decreasing the hardware cost and making the application more efficient and scalable

Posted 20-Nov-12 3:22am

Member 9615321

Updated 20-Nov-12 3:24am

v2

Add a Solution

Comments

Richard MacCutchan 20-Nov-12 10:15am

I think this question is beyond the scope of a simple Q&A technical forum. It looks like it needs the services of an IT business consultant first.

Member 9615321 20-Nov-12 10:26am

yeah you are right, but any suggestions are welcome.. :)

Richard MacCutchan 20-Nov-12 10:31am

I have made a suggestion. You really cannot expect much more from a Quick Answers forum. A system such as you describe is far too important and complex to be able to give anything more useful.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Jason Gleim · Answer 1 · 2012-11-20T07:57:00

I agree that your project is massive and you should contract with a professional development firm to tackle something like this. It is way to big for a group that has never done something like this before.

That being said, we are a software development firm and we are in the (multi-year) process of doing something similar. Our general approach has been to maintain the thick-client (even improving it) to address customer demands while at the same time working to build out a web service layer and interchangeable front ends. In our case, we are tackling chunks of functionality building the web services and one or more of the front-end implementations. These could be ASP.NET (web form and MVC) or iOS or Silverlight or whatever. The result is that the direct calls the old thick-clients make are being duplicated in the web services... essentially exposing the same functionality. We are migrating parts of the think client when the new stuff is ready.

The result is that we have a hybrid thick client and several "webby" front ends right now while we migrate over to the new fronts. Eventually it will be all web service and modern front ends. Provided web services don't go anywhere, we should be good as the UI technologies develop.

This path, by the way, allows us to keep all of our existing logic in the Oracle 10 backend. The web services, in our case, are Java running on WebLogic connecting to Oracle 10 Enterprise. We are handling health care records so it is almost as bad as banking from a data protection & management standpoint.