Putting to Rest Four Myths About Microsoft Dynamics GP Integration Manager

It's year-end and my client, an advanced IT infrastructure and managed outsourcing solutions provider, is going live on Microsoft Dynamics GP. At first glance you may ask, "What's so special about that?"

What made this implementation challenging was the fact that my client was moving away from its 20-year old AS/400, IBM DB2 implementation of JD Edwards, with lots and lots of home-grown solutions that tied into it: the lease tracking and billing system, the web-based order entry system, the shipping application, commissions, expense reimbursement, and the list might go on for a while more.

Due to the nature of the business, replacing these home grown solutions was not cost effective or desirable considering the increased scope and economic impact such replacement would have on the overall project. After all, you would want to do a migration like this one piece at a time, right?

So, where does Integration Manager fit in this picture? Remember all those home grown application integrations into JD Edwards? Well, Microsoft Dynamics GP would now become the center piece for all integrations. So, why not eConnect or web services? Upon the client's request and after discussing the roles each individual played in the accounting staff, it was deemed a requirement that each person be responsible for his or her integrations. Hence, the integrating solution needed to be user friendly, require minimum programming and maintenance, and little to no IT intervention... well that certainly throws out eConnect and web services. This is how Integration Manager was chosen and why I find myself writing this article.

However, after working on this project and pushing Integration Manager to its limits, I have become aware that the tool has been unfairly associated with a few myths:

<... class="become-member ms-auto me-auto">