A ‘Pack List’ for moving into the Business Central Neighborhood
If you were moving somewhere new, especially if it is across the country to a completely new place and time zone, what would you plan to take with you? Do you have dogs? cats? Kids that need to go? A classic car you really want to keep, but needs transported over to your new home too? The same thought process should also apply to moving to a new ERP system. Readying oneself for the ERP move will unearth a lot, but let’s run through some starting points for your BC ‘pack list’.
Writing this article I am thinking not only about the Dynamics GP users, but also the Sage, NetSuite and especially the QuickBooks users - but anyone who is planning a move to Business Central. I am primarily speaking to the everyday accounting team responsible for a big part of the lift; providing clean data for the future-state ERP environment.
First off, the setup of a new ERP requires some really basic information, but I argue it is essential to get this part fully laid out in Excel up front. The ‘pack list’ approach to this article should help kick-start the process you need to go through before signing up for Business Central. In fact, if you already have this information when you sign up for BC, these projects can go pretty quickly. Training becomes the next barrier to entry, but that is overcome with every implementation project by design.
Company Information:
Legal name, address, tax ID number
Location codes, descriptions
General Ledger Accounts:
Strongly recommend using numbers for main account numbers. 4-6 characters is normal.
Rethink your legacy numbers and build a mapping to the future-state numbers for your GL history mapping
Dimensions:
2 Dimensions are ‘Global’ and are available everywhere in BC automatically
Up to 8 dimensions are allowed in the general ledger for BC (vs QuickBooks which only has a single Class)
Rethink your legacy reporting units, profitability centers, codes and descriptions for up to 8 dimensions
Banking:
List of banks
List of bank accounts, routing numbers, and associated GL account numbers
Vendors:
List of complete vendor records you want to keep in BC. I recommend using the automatic numbering series for vendors in BC, so it is not absolutely necessary to keep the old IDs since you are moving to a new system.
List of additional vendor ship-to and remit-to addresses for each vendor if multiple exist
Vendor Banking information for NACHA/EFT setup in BC
Customers:
List of complete customer records you want to keep in BC. I recommend using the automatic numbering series for customers in BC, however there are a lot of external systems that manage the customer number schema, and this is perfectly acceptable in BC as well.
Items:
The inventory module of your legacy system may have the item codes, descriptions and characteristics that need to be carried over to BC, so export everything possible about your items and review which records need to be kept. Some items are part of an assembly or BOM. Some items are actually kits made up of other base items. It is crucial to review and approve this list before loading to Business Central
Fixed Assets:
The asset list and LTD balances often can be a quick and easy export from a legacy system or existing Excel spreadsheet.
Remember, some of the data migration process needs to be done at least twice, once for the sandbox which is used for training and user-acceptance testing, but also again at go-live to ensure all of the right master records and opening balances are in their proper state.
How Much and What Types of “History”
GL History - 2 years GL history, converted to new GL accounts for comparative reporting. Also used to build and validate the financial statements before going live
Bank History - Open / unreconciled transactions for open bank accounts at time of cutover to BC
Payables History - Open / unpaid transactions at time of cutover to BC
Open Purchase Orders - Open / unreceived transactions at time of cutover to BC
Sales History - Open / unpaid transactions at time of cutover to BC
Sales Open Orders - Unfulfilled transactions at time of customer to BC
Inventory History - Open item quantity balances by unit and cost layer at time of cutover to BC. Don’t forget serial and lot numbers too.
There are many more parts of the system to look into if your implementation is on the complex end of the spectrum. They will certainly require more discovery, and if necessary, specialized integrations to load.
So how best to actually deal with all the history in GP or the legacy system?
Are you planning to unplug your GP server as soon as you get to BC? Of course not. Your data is there and can be accessed or moved to another location. But seriously, leave it where it is if you can. Keep an RDP login alive if you need to get into the GP application, otherwise its the data that really matters, which lives in SQL.
I recommend weighing how much history you need to keep, where it gets stored, and how it gets accessed. If you copy history data to the cloud, you can select how much and what data tables need to move.
Analytics, queries, Power BI, and the Power Platform can access, retrieve and report on the required history from GP after pushing to the cloud for safekeeping with this approach.
I also recommend keeping BC for BC data, and any legacy transaction history should be stored outside of the BC database, however ,it can certainly be made available for retrieval through the BC user-interface.
I’m grateful should this experience or these insights be helpful to you on your journey…until next post!