Microsoft Dynamics NAV 2013: How to Approach an International Deployment

April 16 2013

Companies planning multinational deployments of Microsoft Dynamics NAV need to be aware of some of the common challenges and issues surrounding such implementations.

Before you decide to deploy Dynamics NAV 2013 internationally be sure to consider licensing requirements - something your partner can definitely help you with, according to a presenter from an international food manufacturer at a recent online meeting of NAVUG.

About Linda Rosencrance

Linda Rosencrance is a freelance writer/editor in the Boston area. Rosencrance has over 25 years experience as an reporter/investigative reporter, writing for many newspapers in the metropolitan Boston area. Rosencrance has been writing about information technology for the past 16 years.

She has covered a variety of IT subjects, including Microsoft Dynamics, mobile security issues such as data loss prevention, network management, secure mobile app development, privacy, cloud computing, BI, big data, analytics, HR, CRM, ERP, and enterprise IT.

Rosencrance is the author of six true crime books for Kensington Publishing Corp.

More about Linda Rosencrance


JohnKleb's picture

Thanks for this information on this important topic Linda. I wanted to add a couple of my thoughts around the single versus multiple databases concept. We have been engaged in many international deployments of Dynamics NAV with our largest deployment covering 34 countries – most of which did not have any Microsoft supported localization package. First, I would be hard pressed to ever recommend deploying across borders with a single database unless the various country’s statutory and market conditions were closely aligned. NAV is perfectly suited and certainly nimble enough to deploy in a multiple database scenario. And as you pointed out in your article, your approach to localization is critical. There are two ways to approach localization. We have tagged them Traditional and Reverse. I will try to outline the two below, but first we need to understand that the issue is about balance between required customizations for the business and required localizations for the countries involved. Maybe a look at the process would be useful. It would be recommended that you conduct a series of requirements gathering workshops with the key players from each of the countries involved. Don’t come to decisions about requirements from the headquarters alone – you will miss key elements. Then compile the requirements discovered, combine them with HQ driven directives and determine a core set of what we have termed COrporate REquirements (CORE) that embody the requirements that are more or less common in all geographies. Now that we have the CORE defined, we can properly plan our deployment strategy. If the CORE is small and lower effort to create than the localizations, we would recommend using a Traditional localization approach. That is where we would begin with the localized version (Microsoft or partner-based) for each country and then merge in our CORE customizations. (By the way, there are partners in virtually every market that Microsoft does not localize directly that have built and sell their country’s localizations. If you need one for a specific country, let me know ) If the CORE is larger and more effort to create than the localizations, we generally recommend the Reverse localization approach. This is an approach that would have the CORE built in the W1 database (basic database created by Microsoft before localizations are added). This CORE version would become the basis for all countries deployed and then the localizations for each of the geographies are merged into the CORE database. This allows for a clean and controlled management of the customized objects and provides greater control over version management. Sorry for the long “comment” on your article, but this is such a fun subject I couldn’t resist. ;-)