- The current system has be band aided for too long (often breaking)
- The company has grown beyond the original scope of the system
- The fidelity of the data is questionable
- Increased administration overhead of maintaining the data / reports required
- Extending the system to clients and partners is required
- A more User Centred Design (UCD) is desired
- and of course, it needed to be web based.
When looking at migrating a system, it isn’t just a matter of creating like for like functionality. Note that our first project of this kind stipulated that this was mostly the case, and it took some convincing to extend the brief.
So how do we pop the Microsoft Access db in one end and out pops the rails system out the other?
Some of the activities that we undertake are:
- Determine the current pain points of the system
- Determine the desired features not currently available
- Look at the existing forms, external to the system that are being used
- Look at existing database schemas
- Develop scenarios and use cases fro the new system
- Develop the ETL process for the data
Over the course of these projects, we have developed tools and processes to assist with the migration of Microsoft Access systems, and we are ready for the next one!
I can recall back 20 or so years wrestling with Northwind sample Microsoft Access databases, before embarking on that chapter of my development journey, not realising that 2 decades on, I would be revisiting. I wonder if in 2034 I will be recalling my cancan gem experiences?
Post a Comment