Migrating MS Access Front-End to .Net Platform

Do you still have people that can maintain your Access front end? Can these people create and maintain a .Net front-end? Even if you switch to VB.Net, it is a very different beast. Also, there is no automatic converter from Access to .Net.

Yes. I maintain it myself and I have since I built it years ago. It's been enhanced over the years and is a lot more robust with the newer versions of Access. I'm a one-man show and my background is mostly in access. I don't know .net that well but have tinkered with it a bit. And having to re-write all the code is going to be a huge undertaking. I was told to see if we could hire someone who has a .net background who can rebuild this database in .net but before I start that process I want to be sure that moving to .net will gain us more benefits than what we already have.

If by chance down the road the wanted to make portions of the application available on the web couldn't a smaller app just be built for that use and leave the current front-end alone? But as far as performance between an access FE and a .net FE are there any advantages by migrating? Such as speed, stability, etc?

Since your database is stored in MS SQL Server, you can create a second application (a web app for example) that connects to your database and expose some of the data while still having the Access application running. They are not mutually exclusive. The things you need to be aware is that if you create a web application access from the Internet, your database will need to be stored in a place where it is available to the web app.

If your application is currently fast and stable, moving to .Net won't really help. In fact, rewriting your front end will bring some instability for the time you test everything!

This would only be relevant with a Jet/ACE BE.  Once the BE is SQL Server or other RDBMS, an Access FE is infinitely scaleable.

I'd disagree with that point. I find it much more difficult to deploy Access apps than I do .NET apps. The Access apps are VERY environment dependent, and most especially the frontend portion. Trying to deploy a 2013 app to an environment running 2010 means I have to deploy the correct Access Runtime, and run the risk of overwriting the user's default extensions. With .NET, all I need is the correct .NET framework on the end user machine (or build my app to be compliant with the minimum requirements, which essentially means changing a single build setting) and I'm good to go.

Yup, deployment is fun: e.g. corrupted Office installations a.k.a. missing mso.dll ;)

As I mentioned rather earlier with the SQL server BE the number of concurrent users is (probably) not an issue.  One isn't talking of many hundreds or thousands working simultaneously.

Some talk of scaleable when talking about that.  Note that is not the same as distributing an app or access FE.

I truly appreciate everyone's input on this topic. If we do take the plunge to moving this DB to .net it won't be me actually doing the work. They want to hire a temp to come in and actually do the work for us. That takes the pressure off of me for now but I'll still want to learn as much as I can so I can maintain it down the road after the temp leaves. There are good arguments for both sides of this topic and I'm leaning towards leaving it alone but ultimately it's up to the powers that be. I can give them my recommendations but in the end they will make the decision. I wish I knew more about .net already but I've spent the majority of my time learning Access since that's what we've used for years. But it's probably time I start learning the .net world.

@Pat,

What that means is that .Net is a lot less sensitive to its environment than Access is.  With 15-20 users, that would start becoming a consideration, but it doesn't become a serious one until you would get past 40 or so.

This would only be relevant with a Jet/ACE BE.  Once the BE is SQL Server or other RDBMS, an Access FE is infinitely scaleable.  Your constraint is seat licenses and bandwidth on your RDBMS.

 Not what I was talking about. The problem with more then 40 stations as a general rule of thumb is two-fold:

a. having a stable office environment.
b. having a stable network environment

 The first deals with the different versions of office and keeping Access itself running.   The second encompasses the first to some degree along with the OS(s) in use and boils down to the ability to hold a stable connection to the database, and is only an issue with a JET/ACE db.  As you said, with a SQL BE, b doesn't come into play at all.

 In regards to the first, if everyone is standardized on the same version of Office, then 40 is not an issue.   But I've found in general that once you get past 15-20 users, the chances are high that someone will be different, and that means deployment problems and your app potentially breaking, or being a headache to deploy.

 This is where .Net has Access beat hands down.  You install a .Net app, you done.   No fear of anything breaking if someone happens to update Office, install another run-time, or mess with some of the other things that can easily cause an Access install to break.

Jim.

I'd disagree with that point

You are reading a lot more into the comment than I intended.  Just because I could create an Access FE that supports thousands of users, doesn't mean that I would want to.  The point is only that I could not that I would necessarily want to.

Access is always a problem to distribute if you can't stabilize your environment.  It doesn't matter whether you have 2 users or 200 (I've had both).  That is a primary reason Access is rarely used for "boxed" software.  Support costs are astronomical when you have to debug the environment of every separate installation.   In my "200" scenario, we had a very controlled environment so I actually had very little trouble with individual work stations.  The network staff distributed a shortcut for me to new users.   The shortcut ran a batch file on the server to download and run the FE so the FE was always "fresh".   The app used DSNless connections so we didn't need to worry about pushing DSNs.  I controlled the schema so I made sure to not use any data types that the old SQL Server driver couldn't handle so we didn't need to distribut drivers (although the network people could easily have done that if necessary).  The LAN was wired and had decent performance.    I have also been at clients where getting 5 users connected was a nightmare.

Access is not the ultimate in development platforms,  It probably isn't even in the top 100.  In its niche, nothing beats Access for flexibility, ease of development, and yes - power,  but eventually a successful Access app will grow to a point where it needs a different platform.  Until then, it is simply a waste of time and money to replace it.

You are reading a lot more into the comment than I intended

Your point was a little too narrow to read anything other than what you wrote, but perhaps we have different definitions of the word "scalable".

 I do agree that Access is a great platform for many things, and I think that it's well suited for the situation of the question asker, but I can't say it's my go-to answer for environments where you have more than 20 or so users. I've certainly created Access apps that handle more than that, as have you, but it's difficult to do (mostly for the reasons Jim laid out above).