We want to move to a web-based app so we can eliminate the dependency on our physical location for hiring new sales force members.

If that is the main motivation behind your project, please consider not to rewrite the application. If I got your right, you will still have a defined user base, and don’t want your app to be opened to millions of users (that’s what web applications are best for). You also want access to the data only through secured channels.

In such a situation, I guess it will be at least 100x cheaper and quicker to provide all of your sales force members with a windows laptop and a VPN access to your network, and install the application directly on their machines. If deployment of updates seems to be a problem, think about writing an MSI conformant setup for your application and make use of windows policies for automatic deployment.

Also, I would heavily recommend this article of Joel on the topic of “rewrites”: http://www.joelonsoftware.com/articles/fog0000000069.html

Of course, since your backend is a full relational database which can be accessed by many different applications simultaneously, it may be an approach to add new functionality through a web based frontend, as long as that new functionality is not very tight to existing functionality in Access application. Choose whatever technology fits best into your current knowledge stack.

Of course, without knowing the complexity of your application (and the interfaces with Outlook, IE, etc suggest to me that it IS complex), I would recommend the .NET route, since it appears you’re already familiar with a lot of the Visual Studio tools that would be involved. (SQL Server, VB.Net, etc)

While I am not anti-open source, (I like FREE, too), it depends on what you want to bite off. Do the developers in your shop have more experience in the Visual Studio realm, or in the LAMP realm? Is the licensing cost for Visual Studio what is driving people in that direction, or is there a valid technical reason (everyone has to learn all new stuff anyway, and LAMP gives us [significant value item here] and [significant bonus value here] that make it a better choice as we go through the process of change)?

This really depends on how much money is budgeted, how much time you have to do the work, and what the new application will actually do that might be different from the existing application. Sometimes the “free” tools will actually cost more in the time required to learn them and integrate them with what you already have.

First, keep in mind that the LAMP stack might be free to get rolling on but that the costs of ownership are still effectively the same. You still need to feed the servers power and bandwidth and you still need skilled labor to keep things running and secure. Once you get to big enough scale it is pretty much a wash.

I would argue in this case that while making it somewhat web-based could make alot of sense, you’ll probably be looking at something with a central service with several UIs. Moreover, the thing I’d think about more than web is mobile — how are you handling that? Web is yesterday, mobile is tomorrow.

Insofar as answering the question, I don’t think there is a direct one given the facts we know. But in general these days you often must look towards hybrid approaches as most often you’ll need to use bits and pieces of various stacks for the best and most cost-effective functionality.

What is the problem with the existing application, and how will moving to a web application fix that? 120K lines of code is significant. If you already have developers trained in the technologies you are already using, and it’s working well, why would you change? Without answering that question, any evaluation of potential solutions is meaningless. I’m guessing that reliability and speed are two concerns?

You use the term “LAMP stack” loosely. I have always picked technologies that are cross-platform, instead of ones that lock you into a single vendor. Open-source is good if the license fits the way you plan to use it.

It sounds like you have a wealth of Microsoft-specific knowledge at your organization, so you may not want to pay the price of retraining.

As @Wyatt Barnett said, once an application is developed, if the technology you use is appropriate to the task, the cost of maintaining it is not related to the brand-name of that technology.

As far as appropriate goes, 120K lines of code would be a nightmare to manage in PHP, and might be slow in Ruby. Pick something popular so you can find developers as you need them. I’d go with Java or C#/.Net. A lot of people are using Spring with Java these days.

I am in the middle of a similar migration, except we chose to end with a .net front end application instead of a web based.

What we chose to do was to first migrate the business logic out of the Access front end, and rewrite it in C#. It took a while, but we eventually got most of the business logic switched over while keeping the same front end. Once the forms were reduced to visual display, we started moving sections of the application to a .net application. We are now in the final stages of deploying our application as a full .net app with no dependencies on MS Access.

I have worked on a number of significant “Legacy to current” types of conversions over the years. The most successful ones were those that migrated functionality to the new platform at a measured rate.