This idea was evolved when Greytrix had released GUMU™ for Sage CRM – ACT! and GUMU™ for SageCRM – Goldmine and GUMU™ for SageCRM – Maximizer.
With major CRMs supported by GUMU we thought that there was nothing more we could add to the CRM migration source list. We could not have been more wrong (Later on we added SalesLogix, Salesforce, Excel, MS SQL, Access, CSV, and Oracel apart from Telemagic). One fine day we got a request from one of our reseller friends asking if we can assist him in migrating data from a CRM known as “Telemagic” into SageCRM.
For the benefit of those who are not familiar with “Telemagic” let me tell you that it is a blessing in disguise for an end user. It has it own templates for various industries which you can pick and choose. If you are not satisfied with the template you can create your own system with your own tables, fields and their linking. You can have your own entities and the screens and their linking with other entities etc. And to add to this, it varies from end user to end user. In short it is nothing less that a nightmare for a developer :).
The first reaction was “How can we develop a product if we don’t even know the tables and entities that exist?” But after the hue and cry died down, we put our thinking caps on.
It was quite obvious that due to the nature of the Telemagic system, if we attempted to develop a product then the user interface would be very complex as we would have to handle all the tables and each of the fields. An average user would spend more time understanding the user interface than the actual migration. Thus it would beat the basic feature that is a part of all GUMU migration products i.e. simplicity. Hence it was decided that Telemagic to Sage CRM migration had to be a more of a migration service than a product.
Now that it was decided that it would be a migration service we had to come up with a solution of how can we read the data and insert in to SageCRM. Based on our experiences with ACT! and Goldmine we already had the code snippets to write the data into SageCRM. Since we have the routines written in SageCRM webservice this would be compatible with SageCRM.com as well. Awesome!!! We will have to just tweak some code to make it workable for Telemagic. Now we just had to come up with a way to read data from Telemagic. The migration which looked impossible to achieve sometime back, now looked very much possible.
Technically speaking, the Telemagic database is a MS FoxPro database. Even though MS Fox Pro seems to be a very obsolete development language and data storage which only developers in early 90s used, let me tell you something about MS Fox Pro. It has some of the best designs to store and navigate large data.
We have been working with SagePro since the SBT days. In terms of numbers that would be close to 10 years. Hence we already had experts in MS Fox Pro. We decided that we would create a code in FoxPro that will dynamically read all the fields and tables of Telemagic and insert it into SageCRM.
That’s it. We were done with the Telemagic migration. We sent this idea to the client and he was OK with us doing the migration. We got a hold of the Telemagic data and the SageCRM data and successfully completed the migration. Migration costs USD XXXX, Client satisfaction – Priceless 🙂
Later on we used the same concept to do the migration for SalesLogix, Salesforce, Excel, MS SQL, Access , CSV, and Oracel apart from Telemagic.