Dynamics GP failed Data Conversion from legacy accounting recovery
This is not necessary related to GP. When you implement new Enterprise Resource Planning software on the first phase you have to address the question of data inheritance. Some apps have templates or even tools to import data completely or semi automatically. But often what these instruments to – they move in master records only, and what these are we explain below. Good example is Dynamics 365 Finance and Operations (former Project Madeira or NAV) imports master recs from QuickBooks.
But there are tools in certain scenarios which ‘migrate everything’. For example, you can upgrade from Great Plains Accounting DOS/Windows all the way to current Dynamics GP. You can move from Small Business Financials to GP as well without data loss. And also I’d like to mention that you can migrate your reports and all their elements from FRx to Microsoft Management Reporter (we did this for GP only, for AX and SL we do not know)
In our experience we saw botched ERP system initial deployments caused by failure in data conversion from old accounting to the new one. Usually consulting firms are very good in their sales cycle, user training and modules setup. But they may have issues with data export from old database, preparing documents in new format and importing them to your new application. Let’s try to review various methods of extracting information from legacy software.
Direct connection is usually done via ODBC or so-called native drivers. Here you may need some technical steps. For example Pervasive SQL/Btrieve platform needs Data Definition Files or DDF. Some resellers have excellent CPA style functional consultants but at the same time strong technology expertise
Printing reports into text files. This is second method which in contrast with the first one is neutral to DB platform, but requires data ‘massage’. Apparently report has its name, page numbers and footer, plus it may have empty lines to be ‘human friendly’. This ‘friendliness’ makes its data not hundred percent structured or tabular, but this normalization is required for import. So, in order to make it ready for migration you should weed out irregular lines. This could be achieved in either Excel or in the case of huge number of records in SQL custom tables
Let’s now talk about conversion scope. This should be discussed in details and understood by your key decision makers. The decision to bring in ‘everything’ is not a good idea even if it looks natural and reasonable. ERP software typically has its documents flow from initial entry, approval, if needed, and then committing to their permanent status. Plus in General Ledger you have to close the financial year and give ‘fresh start’ to Profit & Loss statement. This is why in the case of GP and other similar apps importing tools bring docs into so-called ‘work’ tables to be reviewed and posted all the way to GL. Moving in historical docs complicates migration as you need to feed them into the whole cluster of tables, including distribution accounts, addresses, taxes, inventory items to begin the list. This is possible, however your implementation budget might be increased dramatically with potential exposure to data inconsistency
Recommended approaches. Think about bringing consolidated monthly GL balances for past few years, master records such as customers, vendors, employees. In order to be able address requests about historical invoices, payments and purchase orders good idea to have legacy accounting available in inquiry regime and closed for new entries and changes. If you had it in Cloud or by subscription you may simply export needed information into MS Access, Excel, tab delimited text file or SQL and be sure that you have it
Migration path. If you have old system for example Great Plains DOS then you may decide to walk away to another platform, for example SAP Business One, NAV or AX. However this path will need conversion. This step could be avoided if you stay with its successor Microsoft Dynamics GP. There is migration tool and all your legacy documents will be transferred
You may contact author, Andrew Karasev: firstname.lastname@example.org 331-330-6879 www.efaru.com