Moving from Dynamics NAV to Dynamics 365 Business Central – Part 2: Data
In Part 1 of the Moving from Dynamics NAV to Dynamics 365 Business Central series we gave an overview of what this process might look like. Part 2 of this series is all about data. Data is the “stuff” you carry with you to your new home in Business Central. Code is the structure of your new home, including any remodeling needed and any services required. These two concepts are not mutually exclusive and the proper order of the conversation around these two points is debatable. More to the point, you can’t put furniture into a room that doesn’t exist, and having a room without furniture isn’t very useful.
We will cover data first, in this post, because it more closely influences your decision on whether to upgrade (moving truck) or reimplement (air freight).
Data and the Upgrade v Reimplement Decision
Upgrading versus reimplementing is the biggest decision you will make related to the project execution itself, although often not the most impactful decision from a budget perspective. In a nutshell, reimplementing is generally cleaner, but you will make some sacrifices. Most notably, you won’t take all your “stuff” with you.
We will first discuss data within the context of the two project approaches. This discussion excludes the concept of any custom data points (fields and tables) that you have created along the way. We will cover that next.
Should You Reimplement Business Central?
In a reimplementation, you start clean in an empty database and then add in only those things (data points) that are wanted from NAV. In the moving analogy, you would be flying a small subset of your belonging to your new home and not sending anything along in a moving truck. There is generally less to worry about because there is less to move.
To start, you minimally identify which master records to keep (ex’s: customers, vendors, items) and which open transactions are needed (ex’s: POs, SOs, Prod. Orders). This data will then also be separated into those things to be loaded into BC through migration code (ex: customers) versus those to be re-entered manually (ex: open production orders).
Records are then ported from NAV to BC, along with limited history, likely including G/L history summarized by month/account/dimension combination, open A/R, open A/P, and item balances. You may also consider other migrations such as stock-keeping units, open bank transactions. fixed assets/balances, and production setups (machine/work centers, BOMs, routers) – as a few examples. Each of these must be shipped independently and unique shipping containers (RapidStart packages or XML Ports) must be built for each.
Most notable in this approach, transaction history is left behind and in-process activities do not port easily (received not invoiced purchases, shipped not invoiced sales, in-process production orders, open jobs). Things you might miss once reimplemented include copying documents from before the conversion, drilling into purchase or sales histories per vendor/customer, general ledger transaction detail for prior periods, change histories to records, and the ability to support an audit without referring back to an archived database.
With this approach, you will arrive at your new home with a kitchen containing some new appliances and dinnerware, but with the cupboards somewhat bare.
Should You Upgrade from NAV to BC?
In an upgrade, all your data comes with you. Because you are moving from “NAV” to “BC”, the data structures are generally the same and the migration of that data is already handled through Microsoft-provided tools. Those tools act like the moving company that has handled hundreds of moves.
If your historical data is not a complete mess (think duplicates in item, customer, vendor lists), or corrupted (think bad inventory valuations), keeping data is generally an advantage. Even in cases where “some” data is bad, that can be mitigated either by introducing map/purge lists or through adjustments to the upgrade process. These activities are the garage sales or furniture repairs of an upgrade.
This process is simpler from a decision perspective because your data just comes with you. Remaining decisions that can creep into the upgrade project are usually related to “bad” data or data adversely impacted by customizations.
With this approach, many rooms will feel like they did before, for better or for worse, and making your first few meals should be a lot easier.
Custom Data and Mapping
In addition to the discussion above related to data “out-of-the-box” fields and tables, a significant consideration of any “NAV” to “BC” upgrade or reimplementation is deciding what to do with all of the custom data points accumulated over the years. During the project, whether upgrading or reimplementing, each custom data point (field or table) needs to be considered. Those data points are then broken into three categories: Keep, Drop, and Other. An example of a custom data point might be “Independent Rep No.” added by your company at some point to the customer card.
We can think of these as more important, smaller items we ship to our new home, but with special care and shipping instructions needed. There are probably a good number of these that might be considered keepsakes and another group that simply seemed worth keeping at the time.
The fields and tables to be dropped are the easiest. We simply leave those behind. Those fields and tables to be kept are also relatively straight-forward. The custom data points are included in the Rapid Start packages or in migration code we build within BC – depending on how our other data is getting there (upgrade v reimplement).
The third category (“other”) is where we can spend some time. While a goal of any project is to deprecate as much custom data and processing code as possible, it is not always clear where to draw the line. The data points that end up in the “other” bucket include those things we are not completely sure if we should keep, those things where we believe a new stock field might suffice, and those things where a larger mapping exercise is needed.
As mentioned above, migration scripts for non-custom data might also be desired. As a first example, your payment terms list has grown exponentially (think a collection of empty wine bottles here). You want to reduce this list to only the ones that have real meaning. As a second example, you may also realize you have several items no longer in use that slow down the lookup process and aren’t needed for historical lookups.
Summary of Moving from Dynamics NAV to Dynamics 365 Business Central – Part 2: Data
There is no one “right” answer to data and the migration path. The answer is dependent upon specific goals, existing data, and timeline. An upgrade is usually a bit more expensive than a reimplementation, but this can also vary from project to project depending on specific factors.
The result should be the same from a to-be workflow perspective. The key difference between these approaches is how much of your “stuff” you take with you.
In Part 3 of this series, we will cover extensions, integrations, and ISVs - and how they impact your upgrade or reimplementation project.