Why I remain a Microsoft Dynamics GP champion

I've had several recent discussions about why I continue to recommend, sell, and support Microsoft Dynamics GP rather than transition to Dynamics AX.  These have been discussions with developers, clients, prospects, business associates, and application consultants, each dealing with a different aspect of the complex relationship between these ERP solutions. I'll provide a comprehensive report of my responses to different questions and concerns, because although my answers overlap, there are also distinct reasons why I remain a GP champion, even as the product evolves in relation to Dynamics AX.

Product Functionality Distinctions

Dynamics AX has powerful and flexible manufacturing functionality. Dynamics GP manufacturing is straightforward, with routings and manufacturing orders. AX can be molded to fit every manufacturing scenario while GP is only used for discrete manufacturing.  In addition, GP's manufacturing job cost and quality control modules are weak.

GP has flexible and comprehensive financial modules including fixed asset management and electronic banking functionality. AX requires third-party modules for fixed asset and electronic banking functionality.

In that AX was initially developed in Europe, its multicurrency functionality is strong. GP has a moderate-capability multicurrency module.

What I Discuss with Developers

Fundamentally different in database design, AX wins out over GP with contemporary programmers. If a company requires and can afford customized functionality, AX is the choice. GP customers will typically look to cover custom needs with a module developed by a third-party. After Microsoft acquired Navision and Axapta (the former names of Dynamics NAV and AX), Dexterity, the programming language used for customizing GP, fell out of favor. In late 2012 and early 2013, Microsoft announced it was reviving Dexterity because they were able to reuse Dexterity code for  the new web client  while Visual Basic ...