A very extensive application began as an Access-based system (for database storage). Forms were written in VB5 and/or VB6. As .Net became a fixture in the development community, certain modules have been rewritten. This seems very awkward and potentially costly just to maintain because of the cross-technologies and extra work to keep the two technologies happy with each other. Of course, the application uses a mix of ODBC OleDb and MySql.

Would you think spending the time and resources to completely re-develop the application under .Net would be more cost effective? In an effort to develop a more stable application, wouldn't it make sense to use .Net? Or continue chasing Access bugs, adding new features in .Net (which may or may not create new bugs between .Net and Access), and rewriting old Access modules into .Net modules under time constraints that prevent proper design and development?

Also, to lend further support to rewriting: I have since found out that when the "porting" to .Net began, the VBA/VB6 code that existed was basically translated to the .Net equivalent. From my understanding, nothing was done to improve performance, or take advantage of new libraries or technologies.

In my opinion, this creates a very fragile and unstable application. With every new update, this becomes more and more visible. As a help desk technician, I have noticed an increase in problems reported. The customers using the software have noticed an increase in problems and are commenting on it.

You would need to prove to your boss (or whoever else will decide) that it pays off. If it is bad enough, you will probably get the goahead. Do not underestimate the rewrite task - you WILL spend much more time than you expect in making it production quality.
–
user1249Nov 20 '10 at 15:01

1

Why does the application use ODBC and MySql?
–
kirk.burlesonNov 21 '10 at 2:48

6 Answers
6

A lot of people discourage rewriting an application from scratch and sometimes I agree with the reasoning. But most of the times I find rewrting the app the least painful solution and anything written in Access needs to be ported to .NET - PERIOD. Don't get me wrong, Access has its place and can provide alot of functionality to an organization, but if it turns into a full-fledged app that people rely on then it has out grown Access.

It would probably not take much time to port the extisting VBA to .NET in a one for one conversion. But that may not be a great solution if the VBA is not very good to begin with. A redesign/rewrite will take longer to write but will in the long run be much easier to maintain.

I am almost always in the camp of rewriting it from scratch where Access is concerned and have not regretted it once.

Everyone here has good answers and have given me pause to consider their viewpoint. Your view, @Walter, is where I am. I do not consider the VB poorly written by any means. But it is VB. The shop has been writing VB since the beginning. I am the new guy with both VB.Net and C# experience. I have been given leeway to write in C#. So, of course, I have ideas and want to get them implemented.
–
IAbstractNov 20 '10 at 15:05

6

+1M for "anything written in Access needs to be ported to .NET - PERIOD". Access is a toy.
–
Steven A. LoweNov 20 '10 at 21:47

1

I can attest to Walters answer. I have personally worked in a project to re-write a buggy C++ web service in C# (.Net 2.0) and a ASP.Net 1.1 web application in ASP.Net 2.0 with AJAX for a major Australian bank. The project was real success and we were a small focussed team of 5. Two things I should point out. 1. We committed to support production issues in the old version until the new version is ready but not add any new features. 2. Unless really critical no new features were added to rewritten code, just a functional feature by feature copy with bugs fixed, performance improvement etc.
–
PratikDec 29 '10 at 5:49

1

If everyone else knows VB, choosing C# instead of VB.net is a poor choice. Just because it has {} doesn't mean its the ultimate for every solution. VB woudl fit a lot better in this case.
–
gbjbaanbJul 11 '11 at 9:23

I agree with the refactoring approach. It is quite likely that this will be a slow process that may take many months to complete, but by moving one feature / section at a time has major advantages including:

The refactoring has been going on for at least a year and is scheduled to continue over the next year or two. It seems that resources could be: (1) better used to maintain the current state of the application and fixing bugs, and (2) design the application to be fully .Net and migrating the current .Net features into the new design. It seems that, with a good .Net core, the application could be more flexible, stable, and more tolerant of adding new features.
–
IAbstractNov 20 '10 at 15:21

Reading the question, it sounds more like the application has been ported, like for like rather than refactoring, which would involve reorganising, changing and testing.
–
PtolemyJan 7 '11 at 17:37

It is generally a discouraged practice to "rewrite" an application from scratch (which is a normal urge most programmers felt at least a few times in their lifetime) because you will go from an app with known feature set (and known bugs too!) to an app with most likely lesser set of features and more importantly - unknown bugs. Users could get frustrated, etc.

You would probably be better off if you slowly refactored your app over a period of time, thereby evolving it's architecture over a longer period of time.

Users are already frustrated. Debugging .Net is a lot friendlier and faster than trying to debug Access. Also, an extensive framework built on a technology that, quite frankly, wasn't intended for such extensive use and functionality is a disaster waiting to happen - especially, IMO, when you start trying to integrate a new technology. Integrating .Net into Access could often mean you are not using .Net to it's fullest potential because of Access limitations.
–
IAbstractNov 20 '10 at 15:30

A big challenge that I experienced with a rewrite of that scale is having to maintain two codebases at the same time. If you fix a bug in the legacy system, you have to make sure the functionality works correctly in the new system, and vice versa. Upgrading one module at a time minimizes that maintenance headache.

A full regression test suite that runs on both the legacy and replacement systems would also be helpful.

This is exactly the challenge...anything that is fixed in the Access base has to be tested for compatibility with the .Net base - and vice versa.
–
IAbstractNov 20 '10 at 15:22

The other downside of the re-write from scratch is that the users don't get anything until you're done. At least with replacing one module at a time, they have a chance to see some improvements soon.
–
Larry ColemanNov 20 '10 at 15:51

I agree with Jas, don't rewrite apps just for rewrite sake. They may never need to be debugged or improved, so why waste time? However, if you feel there is a moving shift in the expertise of your new developer hires away from Access to .NET, you may have to migrate before it's too late. That seems unlikely, but a possible consideration.

Although it may not be profitable from a development standpoint, how is having different applications spread around affecting users? Does it require more user training? Are they making more mistakes. Does it increase the number of support calls because they can't find something?

The biggest change in refactoring individual modules is the way the forms look for the front end, and moving to MySql on the back end. There are some minor functional changes that users have to get used to. But for the most part, there is retraining regardless of the number of modifications, new features, etc. We commonly have crashes in Access (forms, data, etc.) that force a restart of the program even though the .Net portion still has some level of responsiveness.
–
IAbstractNov 20 '10 at 15:14

"Would you think spending the time and resources to completely re-develop the application under .Net would be more cost effective?"

This is not a question that can be answered here.

From the top of the requirement pyramid: someone made a decision which he hopefully can justify with a business plan. In that business plan it should state how many hours+extra costs it takes to convert the application and in that same business plan the benefits are stated also in terms on money.

That is the way to do it. If there is no business plan for it. then the answer is to first work on a business plan traceable to some high level use cases to make the impact analysis to verify the start of the project.

If the original driver of the business goal leading to the change is not even based on money then this person is probably the one paying for it all so it must be done.

If there is no business plan but "it just is done" then try to make one and present it to upper management. Include high level uses cases, costs, hours for redesign, build, extra cost for operations, new training for admin and endusers, project management and potential risks.