I am curious if there is an experienced Software Developer out there who can help me with some questions...

Trying to figure out the amount of work to create a mainframe database. Basically, there is a system that has currently been desgined for a PC (not mainframe). The program has been created using D-Base.

The main function of the software is to collect data inputs and then automaitcally detect abnormalities in the data based off a set of conditions / logic that we have built into the system.

We are now looking to take the PC D-Base program and turn it into a mainframe operating program. As we understand we are not able to use D-Base for the mainframe version. Also, we are looking to make this avaiable to several types of mainframes.

I know this is very generic in scope, but anyone out there been through a similar exercise. What kind of costs are we looking at? What kind of time? Is it something we should go offshore with? How many lines of code are we talking here?

I am not technical at all but looking at a business plan that was presented to me and have some technical questions!

Thanks -
Todd

Way too little data to make any kind of estimate.
It depends on the size and scope of the application, what you want to new application to do and look like (web app, terminal application, client/server solution, etc. etc.), what mainframe you're thinking of, what database engine(s), etc.

But it likely won't be cheap. In most cases you'd effectively have to start from scratch, using the functional requirements of the existing system as a basis for the initial design.
That way you can also avoid duplicating the inevitable mistakes and crud that have built up over the years of maintaining the old application.
And of course you'd need to build a dataconversion that takes data from all the individual databases running now and consolidates all that into the new mainframe database. That program alone (which will hopefully need to run only once after a few test cycles) can cost several man months to develop (I should know, I've written several of them).

IMO you do NOT want to offshore business critical systems. You need to keep the knowledge about your critical systems in-house so you can always have a reliable pool of people to do maintenance. Those people will be far more motivated to work overtime or come in in the wee little hours or weekends if there is an emergency than some guy or gal in the far east or eastern Europe whose only connection to your company is the name on a sheet of paper telling him what he should make.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.