We are moving an Access based corporate front-end into a Web-based App [closed]

Question

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]

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.