Microsoft Dynamics GP Data Conversion – Overview for Consultant

Do not be overwhelmed with potential problems expectation, relax, think about your options and ways to go.  In this small article we would like to give you some orientation on the possible steps to undertake and pitfalls.  First you should think and explore data conversion possibilities and their classification:

• Setup.  Consider transferring existing setup features from your legacy application to GP.  In GP we have clear concept of setup files (compared to master records, work, open and historical records).  The scope if setup is usually limited to company name, users and their access rights to your GP companies, Modules settings: GL, AR, AR, SOP, POP, IV, UPR.  Please try to be patient, before you burst with emotions let’s us give you the argument – setup is typically built into the heart of the MRP architecture, this is why you should not expect it to be transferred by the wizard
• Master Files.  Customers, Vendors, Employees, GL Accounts should be migrated – no doubt about it.  You are the judge – if the number of your customers is 50 or so – you may simply to have somebody of your employees to manually key them in.  If this is not the case (you have 50 thousand customers), then GP integration manager module is needed or if this is too expensive you may have your GP consulting partner to use SQL scripts to bring master records over to GP
• Work Transactions.  GP has concept of work, open and historical transactions, when operator enters invoice it is in so-called work status, when you post it – it is in open status and then you move it to history when your review open files longevity.  When you are migrating from legacy ERP – it is good approach to “post” or transform to equivalent of open or historical status all your legacy transactions prior to migration to GP
• Beginning Balances.  This is very reliable and old accounting wisdom – start your new ERP with new accounting period and all you need to do is enter General Ledger beginning balances for the period
• Keep old system for historical inquiry.  This will allow you to avoid painstaking historical data migration.  In GP historical data is often considered as participating is such decision making scenarios as perpetual inventory cost revaluation, multicurrency transactions: Canadian Dollar/Euro
• Historical Transactions Migration.  First idea is to avoid this – until it is absolutely required.  If you can not avoid it – think this way – I can allow GL historical data migration – it typically doesn’t participate in future business logic (revaluations, multicurrency, etc),  If you absolutely need GP history in modules, such as SOP – consider this approach first.  You enable historical financial periods, move transactions through IM and post them to history.  If you think this is impractical – if you have 100 millions records to be re-posted in history – then you rescue to SQL scripting.  In SQL scripting you should expect new discovery (meaning problems, reported to you from you GP partner, typically meaning going over budget and things line that)