Legacy Application Reengineering (Basic to C#)

[Bruce Schechter]

We currently have a financial application running on an HP 3000, written in
Basic ( the old kind, with line numbers and single-character variable names,
etc) with about 500K lines of code. It uses a no-longer-sold,
non-relational, HP-proprietary database called Image. This application has
many very happy customers, each utilizing it via terminal emulator software
in remote locations.



We are tentatively architecting a phased migration to a .NET solution, for
obvious reasons. Likely, we would first create a cleaner presentation
layer based on WinForms, then migrated business logic off the HP3000 to a
Win 2003 server ( in C# code), and finally move the database to SQL Server.



But.. none of us have experience with a legacy migration/reengineering
process (particularly from such an antiquated code base.) Further, given
our meager start-up funding level, we cannot afford to hire expensive
consultants who specialize in this area.



Does Microsoft provide resources with advice on the reengineering process?
Whitepapers? Web resources? tools?



Also, would anyone recommend good books on this topic? Or any other
websites (other than just Microsoft's)?



Are there conversion tools to convert Basic to C#?



And, my MOST IMPORTANT question (pardon the all caps)... are there "rules
of thumb" for estimating programmer resource requirements for migration
based on lines of code, database schema complexity, etc.?



Thanks,

Bruce

 

[Alan Seunarayan]

I did send you a personal reply but it was bounced back. Can you please
email me?

 

[Bruce Schechter]

Alan,
My email address listed in the posting is an alias for spam protection. I
would appreciate hearing from you at this address:
brucedschek(at)hotmail(dot)com.
Thanks, Bruce

 

[Scot Rose [MSFT]]

Hi Bruce,

Unfortunately the only Migration information really covers VB to VB.Net and involves a .Net wizard, that to me, is shall we say, rather
lacking in depth (If your VB Program is very complicated at all it would take less time to re-write the application than it would to debug what
the Wizard creates)

From my personal experience I had a few GW Basic projects that I had to bring up to date to VB6 a few years ago and it wasn't a picnic
and if memory serves it was GW Basic and HP Basic were (As most Basics then) almost the same animal.

Considering the scope of what you are doing however I would have to say that rather than following an incremental path of trying to create
a new UI to connect to the old database then eventually move to another database that you first start at the Database side and get a copy
of your data to there to work with and begin developing to the new database. then when it is complete roll it out and transfer your data
from the old system to the new (Perhaps even work them in 'tandem' for a bit to make sure the new system is correct before throwing out
the old)

Now Alan that replied to you earlier may have some expertise in this area and you appear to have taken this off line. but I for one would
like to hear about what you come up with.. But as I said before, there is no microsoft documentation available for this type of migration.



Scot Rose, MCSD
Microsoft Visual Basic Developer Support
Email : (e-mail address removed) <Remove word online. from address>

This posting is provided “AS IS”, with no warranties, and confers no rights.

Get Secure!
http://www.microsoft.com/security
http://www.microsoft.com/protect


--------------------

 

[Bruce Schechter]

Can anyone else help with the questions below? Particularly the final
question regarding resource estimates.
Thanks, Bruce

 

[Jon Skeet [C# MVP]]

Can anyone else help with the questions below? Particularly the final
question regarding resource estimates.

I personally wouldn't do it in terms of migration. I'd look at what the
users want, the business rules contained within the current code, and
then start from scratch in terms of design. That way you're much more
likely to get a maintainable system, and it may well be faster anyway.