Managing a Microsoft Dynamics NAV 2013 upgrade: The importance of detailed testing and shared responsibility

For a company with actively maintained integrations to Microsoft Dynamics NAV 2009, planning an upgrade to NAV 2013 introduces some interesting challenges. But as one promotional merchandise agency discussed at a recent NAVUG meeting, successful upgrade projects require many of the same fundamental characteristics, regardless of the technical specifics.

This particular NAV customer, a company of about 70 with "dozens of B2B e-commerce sites" managed web services integrations into NAV 2009 via BizTalk. And while it worked, it suffered from architectural choke points. One was the single-threaded architecture, the presenter told other NAV users. It limited the maximum number of transactions that they could get through in a day, including sales orders, shipments, and even communication with their e-commerce site.

(Editor's Note: For more, join our live discussion of the state of NAV 2013 upgrades on Tuesday, January 21, 2014)

Integration decisions

With integrations at the front of their NAV 2013 planning, they got excited about the potential to develop web services from NAV 2013 pages as a way to improve their integration strategy. For example, a sales order form in NAV 2009 could become a sales order page in 2013, which could then be exposed as a web service.

"We assumed that the publishing of a web service of each page that we needed to automate would be the way to go," the presenter said. "So we just published each page out as a web service and began working on integrations to each one separately."

But that approach did not go as smoothly as the company had hoped it would. They pivoted from web services to XML-based messaging, with better results and a single, universal code unit for the integration ...