I have had quite the history with Magic software. Since 1989 I have been the Magic Software distributor in New Zealand and Australia. Since then I have sold Magic to over 200 software houses, three universities, and worked with companies from almost every sector of the economy. As well as this I have trained over 150 developers in using Magic. It is safe to say that with Magic Software I know what I am talking about.
We had a good run for about 20 years, but in 2010 we begun to feel some pain.
Around this time it had become apparent that customers now wanted a SaaS based application. As well as this the cost structure of Magic Software was too clunky; we were unable to be nimble enough to provide a cost-effective solution to help small to medium sized businesses.
We were now faced with a big question:
How do we put a HTML based front-end on our Magic applications?
We had three options:
1) We could use a front end tool working with Magic broker. My reservations with this option were around reliability. I could imagine having uptime issues with Magic broker. For this reason we ruled out this option.
2) We could work with Magic’s new Angular JS front end. The problem here is that to do so would require a large redirection of resources to becoming experts in .NET and Angular JS. The prospect of this made us feel uneasy as a company we have always wanted to focus our energy on delivering applications to our clients and solving real business problems. As well as this, in our option, it was unlikely that the new Magic front end tool would be truly ready for us to use for a while to come. For these reasons combined this option was unattractive to us.
3) The final options was for us to use a new tool that would give us an ability to manage both the front and the back end of development. We would also need this tool to also be able to integrate with our existing Magic back end. This was the option we ended up going with – and it has been a decision that has paid of handsomely.
We ended up looking around and exploring around 15 different options. After a while it was clear that Aware IM was the right solution for us. The central reason for us choosing this was that it was a SaaS based tool that allowed fantastic speed of development.
Once we had made our decision it was now time to work out how to execute a safe migration from Magic to Aware IM. The following are the features and methods we used for successful migration:
- Magic and Aware IM can both read the same tables.
- Aware IM can write data into a table and then Magic can read that table and from that work out what program to run.
- Soap request.
- Rest request.
We then deployed Aware IM on a different virtual server to the database and to Magic. All this was done on the same network.
We then mapped all the external tales in Aware IM. Aware IM can access database tables in native or external mode. Aware IM can access database tables in native or external mode. Both modes have their benefits therefore we worked with both. this results in creating dedicated tables to run in Aware IM native mode – this has paid off big time for us.
Every time we had a need to call a Magic program we would run with point two (above), however in some instances it made more sense to run with point four: rest request. Rest between the tools is great and has worked well for us.
All of this has allowed us to introduce Aware IM safely and slowly. We have been able to move to a more productive, nimble, and effective engine of development. Looking back, it is one of the best decisions we have ever made. It allows us to deploy multi-tenant applications in a profitable way. Thanks to Aware IM we feel excited by the new business opportunities now open to us.