There are 2 choices for updating an existing 32 bit Microsoft Access Application. Keep it in the Access world or move it to Dot Net.

Microsoft Access is part of Microsoft's long term thinking and it doesn't appear that it will be obsoleted. With the latest release, Access 2010, a 64 bit version has been released which will protect the longevity of Access as the computing world moves away from 32 bits and eventually leaves it behind.

The current Achilles heal in moving to Access 64 bit is upgrading the Application’s 32 bit dependencies, i.e. the 3^rd party controls, ocx’s etc that do not work in Access 64 bit. Right now Microsoft is recommending people stay with their Access 32 bit version if they have any 32 bit dependencies within their App. Over time vendors will release 64 bit versions of their controls which will solve this current problem.

Ribbons are another challenge. Starting with Access 2007, Microsoft has removed the Menu system and replaced it with ribbons. This adds a further step to migrating an existing Access 2003 or older application to the latest version.

Finally, customers these days are favoring SQL Server as the backend and this presents the third issue in Migrating an Access App and making it current. There are some good tools out there that will move the tables and the easily identifiable queries across to SQL Server and render them as views and stored procedures. There is then a manual process of mapping across embedded SQL in code and queries that are not well behaved to fully migrate the data to SQL Server. For this conversion, people ask whether to use an ADP or MDB. The consensus in the industry is to stay with an MDB. Remapping an MDB to an ADP requires a lot more time, Microsoft’s long term support for ADP’s appears to be faltering and the only upside is the developer can view their SQL database from within the design view within Access rather than use the SQL Management tools.

The other choice is to migrate the Access Application to Dot Net. As with a VB6 Conversion to Dot Net, The first thing to consider is Desktop or Web. While Microsoft is trying to bring these 2 platforms together under one common code set (via the Windows Presentation Foundation and Silver light) the reality is it’s not anywhere close to workable for the near future. That means a choice has to be made for which platform to target. It makes better sense to target the web if your business model allows as the set of controls available on the web is a subset of those available on the desktop, so once Microsoft releases a version of Dot Net that will compile to both platforms, it will be much easier to migrate a web app to the desktop than the other way round.

Converting an Access application to Dot Net is not a minor undertaking. There are some good tools available that will map Tables, well behaved Queries, the objects for Forms and the Objects and Record sources for Reports. This leaves most of the code to be manually converted with some help from the tools. This creates an application that looks essentially the same as the original with a stronger code base.

With this approach the design methodology inherent in the original application will basically migrate across with the conversion. At best this creates half of the potential outcome that a migration can provide, the new platform. The potential other half is a redesign on the fly which is where the real potential often lies. Positioning your application to move forward a generation resets the bar and allows your company to take it’s in depth knowledge of your industry and update your software to best in class, unencumbered by its history. SageKey specializes in this type of Migration and works closely with you to redesign the applications as it is being migrated.

We have developed a program that will give a ballpark estimate of the cost to migrate an Access Application to ASP.Net to help clients scale the level of effort required to do a migration. It counts the number of items in an Access App and applies some simple time estimates to each type to come up with a rough ballpark. Once the decision to proceed further is made, we then refine the quote by running the Application through our migration tools to gauge the amount of manual conversion that will be required.