Advantages of migrating from MS Access application to .Net application

There is an e开发者_运维知识库xisting medium-sized application developed in MS-Access which is currently used by just 15 users. We are now in a fix whether to scratch this existing MS-Access application and develop the same functionalities in .Net (may it be Windows or Web) applicaiton. As this is not a huge application, do we have any positives in moving the functionalities to .Net application? A comparision between the two(.Net Vs MS-Access) - in terms of performance, security etc., would be appreciated also the advantages of developing the application in.Net would help me too.

IMHO a general comparison ".NET" vs "MS-Access" does not make sense. You can compare your current application to the expected features / performance / security / etc. of your migrated application, of course, but one has to know more about the details of your application and how you think you will design your ".NET" port.

When you are looking for reasons to justify the efforts of migration, you should ask yourself the following questions:

• Is anyone missing features in your current application which cannot be easily developed using the Access frontend? That would be a good reason to change to .NET.
• Who is doing the maintenance in the future? A C# programmer who has only a little bit experience with VBA, or an experienced Access programmer with none or only a little bit of knowledge about C#? Or are you completely free to choose any kind of maintenance developer you like, so this does not make a difference?
• Are you stuck to a specific MS-Office version with your Access application? Or can it easily be migrated to a newer version? To decouple yourself from a specific Office platform may be a good reason to change the development platform.
• What about your backend? Are you satisfied with that (you can keep Access as a backend even if your frontend goes to .NET), or do you need a real client-server database (in most cases it is possible to keep your Access application as a frontend for that with much less effort than a complete .NET migration)? A CS database like MS-SQL server allows you more simultanous users and has an improved security model (for the cost of administrative overhead, of course), but in fact gives you no argument why you cannot keep Access as a frontend.
• How many of the "RAD" features of Access are used in your current application (for example, the possibility to have an access form automatically switch to a table-like mode, or the reporting capabilities). For some of these features there's no ready-made solution at hand in the .NET framework, you have to solve that differently or with 3rd party tools. That, on the other hand, would be a good reason to stay on Access.

EDIT: here is a more than 10 years old article from Joel Spolsky

http://www.joelonsoftware.com/articles/fog0000000069.html

which seems to be somewhat related to this topic. Read what he thinks about throwing away an existing application to start all over.

MS Access seems to be a good match when your application is mostly a tool to view and edit data records in a database with simple forms that are tightly coupled with the tables' layouts and you need little to no computational logic in the entire process.

I have just finished re-implementing a MS Access application with about 2000 lines of VBA code, 10 forms, 50 tables and 80 queries to Java because it contained a lot of computations and I/O not related to databases. The Java application achieves the same goal in about 18000 lines of code. The effort it took to integrate all the different databases was considerable. This would be a little better with C# or another .NET technology, but not significantly.

It all depends on what your Access application is designed to do.

Instead of comparing .net to Access, I suspect what you really need to compare is storing data in Access to storing data in SQL Server.

Remember that all of the following combinations are valid:

1. Data and front end in Access
2. Data stored in Access, front end written in .net
3. Data stored in SQL Server, front end in Access
4. Data stored in SQL Server, front end in .net

In general if your database and the number of users is growing, but the complexity of the front end isn't, I'd suggest option 3. If both the data and the complexity are growing, it might be worth the whole hog and upgrading to a Windows/Web .net app hitting SQL Server and doing a complete rewrite. This will require more specialist skills and potentially longer development times, but immeasurably more flexibility and more options for tweaking performance.