In my last blog entry, I looked at as a possible replacement for Access databases that were built outside of the IT infrastructure. In this post, I will go over some of the steps necessary for IT to take ownership of these little unsupported applications that have become mission critical and re-platform them into the IT infrastructure.

Let’s start with the scope of a single Microsoft Access application built by a non-IT person outside of the IT infrastructure before figuring out the en masse process.

Make some assumptions…

  • Target technology is assumed to be X (where X is your favourite web technology).
  • The source database is not compliant to corporate naming standards.
  • The source database will not port properly to anything except SQL Server (I’m thinking there is a little bit of bias here).
  • The source database probably may or may not follow rules of data normalization and/or meaningless id fields.
  • The UI is probably very “access-y” and will not follow web or mobile UI standards.
  • Converting the Access Reports will be a double plus un-fun experience.
  • The User base may resist the workflow and look and feel changes.
  • There will be new business requirements.

First – Initiation

  • Does the application meet all of its functional requirements?
  • How do we prove that it meets all of its functional requirements?
  • What functionality won’t/can’t be converted due to technical, political, security constraints?
  • How will we sell the lost functionality to the business?
  • How will we sell the required new functionality to the business (security model, additional screens and tables for multiuser configuration)?
  • Are there any documents available (business, technical, emails) for the application to ease the replatforming tasks?
  • What are the security requirements to move the application into the infrastructure and possibly move it to the web?
  • Which features need to be mobile?

Second – Estimating and Planning

  • How long will it take someone to build out the project plan and estimate based on the existing application?
    • Example: Have someone go through the application/database and document the tables, screens, use cases/user stories with a simple T-Shirt Sizing Estimation. UML/BPMN diagrams are always appreciated.
  • How long will it take for someone to wireframe the new web-based interface?
  • How long will it take for someone to wireframe the new mobile web-based interface?
  • How long will it take for someone to document the table structure conversion to corporate standards?
  • How long to interact with architecture to get everything approved?
  • How long will it take to write the database conversion scripts?
  • How long will it take to write the test cases and execute them?

Third – Architecture and Design

  • Will the replatform have its own database?
  • Will it use other databases and share data? Employee, Product, Service, Inventory…
  • Will middleware be involved?
  • How many tiers does Architecture require it to have? (UI, Web Controller, Web Service, Middleware, Integration, Database, messaging…)

Skip a few Steps - Return on Investment

By now the department sponsors have signed-off on the project because they really want their mission critical database available to their smartphone from the web. So, what is their Return on Investment because they have lost the ability to work on the application themselves?




New app is under the security blanket of IT (backups, security, helpdesk support).



Cool Web Application.



Look at my new cool app I can access from my smartphone!



Revitalized application with new cool widgets (assumed).



Could cost $750 per day for changes/new features.



Under the umbrella of IT and Corporate Procedures.



Hmm, depending on what type of company this application is for, that is a pretty weak reason to migrate one application off Access – corporate overhead can’t hire an inexpensive summer student to make application tweaks. The cost would make most managers cry, but that can be offset by the security blanket of nightly backups and helpdesk support. It truly depends on the Business Process Improvement savings to move off Access and the increased productivity gains for that application to be converted and web/mobile enabled.

Of course, if this is to be a standalone application, why hasn’t IT already got this built?


Even though we have an already built application, and therefore have a “complete” set of requirements, it is not a straightforward task to migrate or convert an application from one platform to another. Doing so could leave you with lipstick on a pig instead of leveraging the new bells and whistles that the target platform has available.