Mistakes to Avoid When Migrating from GP to Business Central
You took the time to evaluate various accounting software packages, and you chose Microsoft Dynamics 365 Business Central (BC). Congrats! That is no small feat! You’ve probably already started a to-do list to have a successful implementation, but below are some suggested activities you’ll want to avoid.
- Customizing BC to function exactly like GP.
- BC was developed with concepts from NAV and GP and continues to be enhanced with suggestions from users. Change is hard, but we encourage you to embrace the new perspective BC offers. Also, customizations could need costly modifications due to changes made in the semiannual BC updates.
- Migrating all master records.
- Obsolete data is not like those jeans you wore in high school that will eventually come back in vogue. Purge those cards that haven’t been used in a transaction in the last two or more years and feel the weight of those long lists fall off.
- Keeping every single existing G/L account.
- BC has a life-changing concept that you will adore when creating Account Schedules (BC’s version of financial statements). With GP, you have to create the fully qualified account number before posting a transaction to the account. If you’re a bakery using BC, you can have a single revenue account and differentiate the transactions in that account with Dimensions. You can have a single Dimension Code named Dessert with Dimension Values of Cake, Cookies, and Other. Or, you can have three Dimension Codes with more specific Dimension Values: Cake – Carrot, Chocolate, and Red Velvet; Cookies – Gingerbread, Mom’s Chocolate Chip, and Snickerdoodle; and Other – Brownies, Mints, and Petit Fours.
|GP Account||YTD $||BC Account||YTD $|
|4000 Carrot Cake Revenue||5,000||4000 Dessert Revenue||100,000|
|4001 Chocolate Cake Revenue||25,000|
|4002 Red Velvet Cake Revenue||12,000|
|4003 Gingerbread Cookie Revenue||13,000|
|4004 Mom's Chocolate Chip Cookie Revenue||30,000|
|4005 Snickerdoodle Cookie Revenue||5,000|
|4006 Brownie Revenue||2,000|
|4007 Mint Revenue||2,000|
|4008 Petit Four Revenue||4,000|
|Single Revenue Dimension|
|3 Revenue Dimensions|
|Chocolate||Mom's Chocolate Chip||Mints|
|Red Velvet||Snickerdoodle||Petit Fours|
Then you can pair either option with a Dimension Code named Season to further analyze your revenue.
Account Schedule: Income Statement
Filter for calendar year
Dimensions: Cookies and Season
Cookie Revenue Total Winter Spring Summer Fall
Gingerbread 13,000 10,000 3,000
Mom’s Chocolate Chip 30,000 15,000 2,000 3,000 10,000
Snickerdoodle 5,000 2,000 500 500 2,000
- Failing to validate imported data.
- At a minimum, you should validate the number of records imported as well as skim the list page in BC after the data is imported and look for any obvious errors. Reviewing a sample of at least 10 records in detail is advisable.
- Failing to tie out the value of outstanding items at cutover to the balance in the control G/L account.
- The open invoices and credit memos that are imported into BC should be dated the day before go-live so that the Aged Accounts Payable report at cutover can be tied out to the Accounts Payable balance just before go-live. This will narrow down the population of transactions to evaluate if the next month’s Aged Accounts Payable report differs from the Accounts Payable balance. The open invoices and credit memos that are imported should affect the Vendor account type, the Balancing Account Type will be G/L account, and the Balancing Account Number should be the Accounts Payable account so there is no net effect on the Accounts Payable G/L account balance. It’s important to do the same validation on other control G/L accounts like Accounts Receivable and Cash.
- Failing to test several of each type of transaction prior to go-live.
- BC uses a variety of Posting Groups to assign accounts in transactions, and it is important to enter enough transactions to allow for testing of all combinations of the Posting Groups. Also, be sure to test each combination of workflow approval scenarios.
- Failing to have the check format and EFT file reviewed by your financial institution.
- There are strict requirements for the MICR line on checks. If that will be printed from BC, you will want to send a test check to your financial institution for review. Most financial institutions will indicate they accept the standard NACHA file for EFTs, but often there are modifications to that standard format. Consequently, creating a test file for the financial institution to evaluate prior to go-live can help avoid disruption in paying vendors.
- Failing to enable archiving of quotes and orders in the Purchases & Payables Setup and Sales & Receivables Setup pages.
- In BC, once a quote is turned into an order, it is completed and will disappear unless the archive option is set. Orders disappear once all items are invoiced or canceled unless the archive option is set.
- Failing to flip the toggle switch for Direct Posting to OFF for control accounts (cash, A/P, A/R, etc.).
- To prevent an entry being made to the G/L account rather than the Bank Account, Vendor, Customer, etc., flip the Direct Posting toggle switch to OFF for those G/L accounts.
- Failing to set up Dimension requirements for master records (G/L accounts, vendors, customers, etc.).
- If each transaction that will appear in a G/L account should have a Dimension Value, set the Dimension for that G/L account as being Code Mandatory or Same Code. You also can set Dimension requirements on the Vendor and Customer cards.
Reviewing these 10 items can help you have a successful migration from Microsoft Dynamics GP to Microsoft Dynamics 365 Business Central. For more information, reach out to your advisor or submit the Contact Us form below.