Open Forum

Like what you see? Discover the benefits of the D365UG/AXUG Community. Learn More

1.  Data import/migration

Posted 03-20-2017 18:06
Hi All,
When you bring data from the legacy system into AX, how many years of data did you bring?

For GL, is it 2 years?
For AR & AP, is it also 2 years but with detail transactions.
What about Inventory? 
What is the common practice in importing data from the legacy into AX? 

Kim Johnson

Chicago IL

2.  RE: Data import/migration

Posted 03-21-2017 03:21
Hi Kim,

Usually I try to avoid bringing in history. Just convert opening balances for customers, vendors, assets, etc. Then complete an opening balance.
Downside of historical data is that reconciliation reports between e.g. customers and vendors for ever will show differences if you post on the centralization accounts directly.

kind regards,

André Arnaud de Calavon
Kaya Consulting
The Netherlands

This post is my own opinion and does not necessarily reflect the opinion or view of my company, Microsoft, both its employees, or other MVPs.

3.  RE: Data import/migration

Posted 03-21-2017 06:08
Edited by Dave Phillips 03-21-2017 06:31
Hi Kim -

I second the advice given by André.

I like to think of leaving transactional data behind as an implicit archival that saves current and future time/resources.

You can always put key legacy data in cubes, for example, so it can be viewed but keep that legacy data out of vanilla tables and calculations.

The old adage garbage in, garbage out (and performance too!), is so true with migrated data. If there is no choice, transactional data must come over, then have a frank, documented talk with your partner about who is responsible for data integrity and data migration. Also, find a mechanism (e.g. CreatedBy field) to flag the data as migrated so that later troubleshooting can sort out migrated versus new data.


Dave Phillips
Fargo ND

4.  RE: Data import/migration

Posted 03-21-2017 06:16
Hi Kim,

Completely agree with the others - bringing GL history is not a huge deal (depending on volume), but subledger data is a minefield.  It's a good time to clean up data - vendors and customers, and rethink business processes too.  

We normally bring over: GL (summary 2 years, detail up to 1 year), open AP invoices, open AR invoices, asset balances, open bank items.  If including procurement and sourcing, we will usually also bring over inventory balances, open PO's (balance only) but sometimes the users enter the open items instead - it provides a learning experience and ability to really confirm items are open.  Manufacturing adds even more beginning items too of course.

Shirley Adams, Solution Architect
AKA Enterprise Solutions


5.  RE: Data import/migration

Posted 03-21-2017 09:51

Our company also did not bring over detail history.  We entered an ale to bring in one year of history for the prior year so that users could run budget vs actual reports for the prior year and could see comparison data during the first year after conversion.  We are a county government and reply a lot on budgets and revenues reports, revenues by month etc.  So we also created a custom table that housed the revenues and expense information for five years of historical data.  We used Atlas to read this table and created some reports for this comparative data.  Management Reporter may well do the same thing. We will keep our legacy system up and running to maintain our required five year history, but have found we rarely need to go back.

Patricia Allen
County Auditor
Walker County Texas
Huntsville TX

6.  RE: Data import/migration

Posted 03-21-2017 07:58
Hi Kim,

We brought 1 year of monthly ledger balances for the GL and open transactional data for vendor, customers, and bank.  You should definitely clean up all you can prior to migration for those transactions as well as the vendors and customers. 
We posted all these open transactions as journals and set up offset accounts to post these sub ledger transactions to so we could easily validate totals plus had an offset to correct the GL from the double posting (one from the GL posting and one from the sub ledger posting).  We changed our invoice and PO numbering format to easily distinguish between the two systems.
This worked well for us.  Our consultants advised bringing balances only for the vendors and customers but with our volume that would have been a disaster.  Some of our customers have 2000+ open transactions at a time so no way to know what is still open without a lot of extra manual work if we had brought balances only.
Hope that helps with your journey.

Karen Morrell
Forney Industries, Inc.
Fort Collins CO

7.  RE: Data import/migration

Posted 03-21-2017 09:09
Thank you all for taking the time to respond to my question.  I find your feedbacks very useful. I appreciate it. 

Kim Johnson

Chicago IL

8.  RE: Data import/migration

Posted 03-21-2017 09:37

Hi Kim

Migrating data from Legacy system is subjective, time consuming and need good strategy to overcome hurdles later in the game.

If you have an AX system which is already in use you might have archival process in place (say x years) then it is safe to migrate same years of data.

Assuming you are implementing AX newly, your company has no prior experience in AX and have an implementation partner you might have to decide on your archival period (say 3 or 4 years) and migrate that much amount of data. This will help you in load and performance testing as you are mimicking your system as 3/4 years old with respect to amount of data.

Bottom-line is you must decide on archival period based on your business requirements, auditing needs to know how old data you need and plan your data migration.

Pranay M
Web Developer
WestRock Merchandising Displays
Winston Salem NC

9.  RE: Data import/migration

Posted 03-22-2017 10:20
Thanks all for the responses, we are also going through a new implementation and asking ourselves some of the same questions.

Kirk Anger
London ON

10.  RE: Data import/migration

Posted 03-23-2017 10:00
I might also add that there are a couple of ISV's that offer modules for data migration that expedites the process as well. What is vanilla in AX is a bit slower and more cumbersome to use. I don't want to get into specifics and sound too "sales-ie" if you will, but my understanding is that some of the modules are 10-15x faster migrating and cleaning data as it comes across from your legacy system into the AX environment. 

I would be happy to further discuss, but only if you are interested in engaging...i.e. I won't pester you or anything :). 

Joshua Hatton
Norwell MA