We have an enterprise application with a front end written in Microsoft Access 2003 that has evolved over the past 6 years. The back end data, and a fair amount of back-end logic is contained within several Microsoft SQL Server databases. This front end app consists of around 180 forms, and over 120,000 lines of code, and interacts with VB.Net DLLs that support various critical functions used by our sales force. The current system makes use of 3 monitors to display various information; the Access app uses COM+ to control Microsoft Outlook and Internet Explorer for various purposes. The Access front end sometimes occupies 2 screens, automatically resizing itself based on Windows API-reported screen dimensions. The app also uses a Google map to present data to our agents, and allows two-way interactivity with the map through COM+ connectivity to JavaScript contained in the Google map.

At the urging of senior management, we are looking to completely rewrite this application using some web-based technology, such as ASP.Net or perhaps a LAMP stack (the thinking with the LAMP stack thing is "free" is pretty cheap).

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. Currently, our main office is full to capacity, and we need to continue growing the company.

Does anyone have any thoughts on what would be the best technology to use for a web-based app of this magnitude? Keeping in mind the app is dependent on back-end services on our existing infrastructure. The app handles financial data and personal customer data, among other things.

[I've looked at Best practices for moving large MS Access application towards .Net? and read the answers, and most of the comments. Interesting reading, and has some valid points, but our C.O.O. and contracted Software Architect are pushing for a full web-based app, not a .Net Windows App]

  • 2
    When you say "best technology", it seems like you're assuming that you'll be able to do "one-stop shopping" with one technology. With an application of your size, I think it's safe to say that that's impossible. // P.S. You mentioned a C.O.O. and Software Architect. What exactly is your role in the decision-making process?
    – Jim G.
    Sep 6, 2012 at 16:31
  • I Downvoted because of the way you phrased your comment. Sep 6, 2012 at 17:46
  • 3
    I'd like to see more questions like this on programmers
    – psr
    Sep 6, 2012 at 17:51
  • 2
    There seem to be a lot of questions around here in the realm of "what is the best architecture/technical solution for me?" without providing very much detail. While I think that providing a fully comprehensive understanding of the organization is nearly impossible, I think you did a good job of providing important details. Sep 6, 2012 at 17:56
  • 1
    Does anyone on this project have experience building web apps? What would be an example of a team fluent in .NET where they would decide to use LAMP if given a choice or visa versa?
    – JeffO
    Sep 6, 2012 at 18:23

5 Answers 5


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.

  • Good answer! Upvoted. I just read Mr. Spolsky's article - he sure makes a great point! Our network admin wants to provide thin-clients to our sales force (they are not mobile), with access to the app through Terminal Services, etc. I agree with him. Sep 6, 2012 at 17:13
  • @MaxVernon: of course, if Terminal Services is fast enough, that's also an alternative.
    – Doc Brown
    Sep 6, 2012 at 17:24
  • I get the impression Joel is referring more to a product that is sold to the public, not an in-house Access app that's been poorly cobbled together over a number of years. BTW, Terminal Services and the kind of app described have numerous issues, such as mystery crashes and lost data. They'll work, sometimes, but they'll drive a support staff nuts.
    – jfrankcarr
    Sep 6, 2012 at 17:42
  • @jfrankcarr: what I read in the posting is "we have a praxis-hardened application, solving a lot of requirements, gathered over the years, some of them hard to rebuild with web technology". Honestly, I don't find anything in the posting to support what you are writing. And even if you are right, what makes you believe a rewritten application will have less issues?
    – Doc Brown
    Sep 6, 2012 at 18:34
  • 2
    @MaxVernon: actually, the reasoning for rewrites goes almost "this old system is crap, see this new shiny technology, let's rebuild the old system with it, we have the vision that everything will become better then". Is this political or technical? I think it is part of both. But the reasons why rewrites tend to fail very often is that the people underestimate the dynamics and the difficulty of such a task - and thats neither technical nor political, this is an organizational problem.
    – Doc Brown
    Sep 7, 2012 at 15:13

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.

  • Thanks for that thoughtful comment. Upvoted. The issues are just as you suspect, both reliability from an exception handling point of view, and speed of the user interface are both concerns. Sep 6, 2012 at 17:49
  • 1
    I'm a Java fan. Its trade-offs between reliability, speed, and maintainability are about right for the problems I tend to solve. It doesn't have great tools for web front-end development though. I mean they are OK, but not PHP or Ruby/Rails. If I were you, I'd weigh Java goodness against the programmer knowledge you have right now in C#/.Net. C# is pretty similar to Java, but C# is designed to be easier to work with and Java more reliable. Someone will disagree, but that's my take. Sep 6, 2012 at 18:18
  • Linux is so full of developer tools and so reliable, fast, and lightweight, it's hard to not like it as a server and development environment. Once again, your Microsoft technologies won't run there (well, Mono will, but that probably won't help you). Look into PostgreSQL instead of MySQL - Postgre uses the Apache license and can be distributed with closed-source software for free. It's also faster, but requires more work to set up. Maybe you stick with SQLServer so you can keep something the same? Sep 6, 2012 at 18:20
  • "120K lines of code would be a nightmare to manage in PHP" - if you code it like crappy open source forum software, then sure, it'd be a nightmare. If you code w/ strong OOP fundementals, its no more difficult than 120k lines of anything else. Sep 7, 2012 at 4:23

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.