Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Lets pretend that a very large company (revenue numbers with more than 8 figures) is looking to do a refresh on a software system, particularly the dashboard used by employees. This system was originally put together in the early 1990's to handle inventory tracking and storage across a variety of facilities (10+). Since this large company is now in the process of implementing some of these inventory processes with SAP they are in need of a major refresh.

The existing system:

  • Microsoft Access project performs dashboard duties
  • Unique shipping/receiving configurations at different facilities require unique forms and queries within the Access project
  • Uses 3rd party libraries referenced by Access to directly interface with at control system (read: motors, conveyors, and counters)
  • Individual SQL Server 2000 instances (some traces of pre-update SQL Server 6.0 documents) at each facility

The Issue:

  • This system started as a home brewed inventory tracking scheme with a single internal sponsor who is still in charge of the technical direction. The original sponsor prescribing the desired deliverables that are being called for in the current RFP.
  • The RFP describes a system based around a single Access project.
  • Any suggestion that Access is ill suited for a project of this scope are shot down under the reasoning that "it works for the scope now".

Are there any case studies, notices, or statements that can be used to disuade this potential customer from repeating their mistake? Does Microsoft make any statements directly about when it is highly recommended to ditch Access?

EDIT: To answer some of the comments below, the system is getting a rewrite no matter what due to the need to integrate a even greater push towards the deployment of an ERP solution. Problems with the current solution involve additional maintenance of ODBC connections, Office deployments, deploying an Access file to hundreds of workstations, and about 15 years of someone who doesn't know how to program generating enormous amounts of technical debt.

share|improve this question

closed as not constructive by gnat, Robert Harvey, Walter, Eric King, ChrisF Nov 9 '12 at 16:24

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

9  
In my experience access does a fine job of discouraging use itself –  Jimmy Hoffa Nov 8 '12 at 5:57
2  
Here's an outdated but impartial document from MS about when to migrate from Access to SQL (Word doc). It outlines some of the concerns about Access, including scalability, security, reliability, etc. It is quite outdated, so I would use it as a starting point and validate the various arguments individually. –  Daniel B Nov 8 '12 at 6:25
8  
You haven't stated why you believe Access is a mistake in this scenario –  Robert Harvey Nov 8 '12 at 6:26
3  
@Robert Harvey -- more than one concurrent user, operational data, business critical processes. Any one of these three would preclude any sensible programmer recommending Access. –  James Anderson Nov 8 '12 at 8:03
2  
@Greg Buehler : easy, a case study that proves to the customer that moving away from access will make them more profit will do fine. –  Pieter B Nov 8 '12 at 8:17

2 Answers 2

up vote 11 down vote accepted

I'm not sure if the customer really "made a mistake": They had a solution which started with a very small initial investment, which could be maintained in-house, which grew together with their reqirements and which just worked. If the current solution "works for the scope now", the argument that Access is completely unsuitable for a project of that scope has, in fact, been disproven by way of a counter-example.

That said, we are really taking about two different things here:

  • Access as a backend database: This is really something that should be avoided, for multiple reasons. The most obvious one, and the one that each customer will understand, is the fact that one client crashing (e.g. a power failure on a PC) can easily lead to corruption of the back-end database, including data loss. However, since you mentioned that there are scattered SQL Server instances, they might have made this step already and moved away from an Access backend.

  • Access as a front-end, i.e., as a user-interface to an SQL Server backend: This is a different story altogether. Yes, if you have every worked with modern languages for a considerable amount of time, having to write VBA will make your stomach turn: No functional features, very little object-oriented features, very poor version control support, a big binary file containing all your code, lots of problems for multiple developers working on the same project, forget about unit tests, no ORM mapper, etc. Unfortunately (for you), there are also a few points in favor of Access UIs (even for large projects):

    • VBA usually suffices for the business requirements of most database applications. It can do transactions and it can manipulate data, and in many cases that's all that's needed.
    • A lot of stuff is built in. You have a table that just needs a UI for simple CRUD operations? A few clicks and you're done. This keeps initial development costs extremely low.
    • The report generator is extremely powerful, and the ability to customize reports directly at the customer's venue is loved by customers.

What's worse, the customer already has tons of code written in VBA, so rewriting everything from scratch is almost certainly more expensive than "cleaning up" the Access-based solution (remove the worst atrocities, move critical parts to .NET and call them from VBA, separate front-end and back-end if not done already, etc.).

In the end, you will have to make a business case to the customer, i.e., to show him that rewriting everything in technology X will, in the end, save him money. From my experience with legacy Access applications (I've seen a lot and my company also maintains a few for customers), this is a very hard thing, and you need to be prepared that the outcome might be that Access is a valid alternative in this case.

share|improve this answer

To sell change to management, look at things from a business perspective:

Where is the company heading? What will the application have to do in 5 to 10 years time?

Is Access really the best option for providing a cross platform solution?

In what ways will Access cramp the company? In what ways will an alternative solution help it grow? Is an alternative capable of providing a more flexible system?

Can the same code be used in a desktop ap and on the web and in a phone ap?

... how will changing make the company money?

I don't know the answers to these questions, but they are ones that the people you need to say 'yes' need answers to.

share|improve this answer

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