Overview

EZImport simplifies retention of legacy data when moving from another ERP system to Dynamics GP.

A typical data migration requires many tens or hundreds of hours to carefully map, clean, and transform data from the legacy system so it is compatible with Dynamics GP. This is necessary to bring the data into GP Sales Transaction or Purchase Orders, for example, because the GP maintenance routines (Check Links and Reconcile) validate data in the history tables and will attempt to “fix” any invalid data. If a Customer Number or Item Number in a history table does not match a Master Record in GP, the maintenance routines will generate errors.

Since the financial effect of historical transactions has already been recognized, the only purpose for brining over history is to maintain the historical record for inquiries and reports. Not bringing the data forward would mean losing a Customer’s or Vendor’s History.

It is the requirement to maintain “valid” data that makes the data migration so time consuming and expensive.

EZImport eliminates this problem by providing a mirror set of transaction history tables that have NO data validation requirements. Data can simply be “dumped” into the tables from the legacy system. EZImport provides Inquiry windows inside GP to view the imported transactions, and SmartList Builder objects which present a combined view of the imported history along with all new transactions created inside GP.

By removing the data validation requirement, imported transactions do not need to be made “compatible” with GP—for example, if the old system does not have Unit of Measure Schedules, you do not have to “map” the old transactions to a U of M Schedule in GP, you can just import it into the EZImport transaction tables using whatever data is available (which might mean not having a UofM on the transaction line).

EZImport tables also allow NULLS, where each field in a normal GP table requires a value. This simplifies the import even further because legacy data can simply be mapped to a compatible field in the EZImport table, while leaving all of the other fields blank. It is no longer necessary to figure-out how GP wants every field populated or calculated.