Migrating Concodr XAL dat i to Nav 2009

Are switching from Concord XAL after 16 years to Nav 2009 and I’d like to try and get ALL historical data (customers, order history, prices paid, etc…) into Nav. We know some fields are different and will need to adjusted for Nav. Can anybody tell me the best way to achieve this. If say we only imported the last 2 or 5 years for now so we can get Nav live and up and running could we clean and adjust all the ealier data and bring this in as its clean and adjusted to the correct Nav format?

Many thanks,

Andy

Just bring it over as Item, Customer and Vendor journals and post them.

Hello David,

You make it sound very simple… I’m not great with XAL as I had little hands on involment and Nav is only just being installed. Is there any of a step-by-step papers. Do we need to export in a ceratin way? Do we export to Excel and then imord by mapping fields.

I have just orderd a copy of your book. Is there anything in there about importing data from XAL to Nav. Will it bring over all history? The fields in XAL don’t match Nav exactly, but I know you know that.

Thanks Andy

There is no pre-set migration routine for XAL to NAV to my knowledge. You need to decide what you want and map it across table by table field by field.

This means you need to be able to export from XAL - the easy bit really.

Then you need to decide how you are structuring NAV, then you need to see how the data matches, and then you need to make decisions on the gaps and the changes in structure.

If you are not great with XAL and have little involvement with NAV I would not even bother attempting this. You need to write dataports in NAV to perform this sort of work, these will be dataports into open general journals, item journals etc, and then post them as David suggests.

Getting history across is painful, lengthy and costly, you need to consider VERY carefully the value this has in the new system and new structure, but if you are going to do this yourself I advise you start with the static data and see how you get on with this.

With XAL although it is the predcessor of AX and AX and NAV are in the smae stable do not assume there are preset scripts to migrate data. There are no data scripts from XAL to AX. XAL and NAV have completely different table structures as you are discovering, and you will need to find these out, as well as deciding how you are going to use and configure NAV before you can make any real decisions on the data migration.

When migrating systems we move opening balances, open orders, inventory position, open items.
Wea always tell the users to re-create open sales and purchase orders manually in the new system.

We leave all historical data in the old database/application and make it read only so that user can read but not modify the old system.

Do you have a clear requirement from your users on what is required and when it should be transferred?

Its interesting when I read that people have a set way to do a migration. I have found that every client has different needs. Some need open balances, some need 2 years history, others need 5 years some need everything. Often I see clients that need the current financial year plus one closed years, except sales they need 3 years.

Sometimes I recommend linking the old server though SQL, sometimes just to keep the old system running. Often the old data is of no use and printed paper work is all that is needed.

The point is that i see over and over partners that have a fixed way of migrating, but many clients that need something different. I am not saying that its wrong, just that in many cases the customer does need that history.

I remember a migration once where the client had about 19,000 open sales orders in various stages of shipping/invoicing, there was no way they could manually enter all those in a weekend. Also they calculated inventory requiremetns based on the last 3-5 years trends, so they needed sales history.

Recently I worked with a customer that needed 3 months history, and any order not shipped after a week could simply be deleted. So they had less than 100 orders to enter, yet they had about 200,000 Items and about 90,000 customers.

In the end I think the most important factor is how clean the data is. If its a mess, (as we often see) then its probably more damaging to bring it in that to work without it.

But as I say every migration is different.