Importing History from Old ERP System

We are about to go live in 30 days on Kinetic and would like to bring over the past several years of history (ie: sales orders, PO’s, etc) from our soon-to-be former ERP system. Any recommendations for importing that history without having to recreate all of the individual transactions?

1 Like

@grant-rb there is a license you can add to DMT for importing historical data.
I’ve done other things in the past with UD tables or external baqs. Start with the DMT route.


Setup some UD tables to hold that historical info. If you do it right you might even be able to relate them to your live data. I mean you could make BAQs that use a union to combine live and historical data into reports and dashboards

I have heard about, but never seen it in action.

I take an entirely different approach: don’t do it!!!

What people want is access to history. That is a very valid request. If it HAS to be in the Kinetic database (:person_shrugging:) then go UD tables. This will increase the size of your database, backups size and time, etc.) then use UD tables as mentioned above.

You’re running short on time, but my preferred method is to create a webapp to the historical data and embed that site in Kinetic. This benefits are:

  • It’s available inside and outside Kinetic, so no license used to access it.
  • It reduces the size of your database which make backups more efficient
  • Upgrades are easier since there are no customizations to upgrade
  • You can still create your own REST calls that combine the results of Kinetic and your legacy application to make it easier for the users.

But that’s just me…YMMV


110% agree with @Mark_Wonsil !!

The only time I would agree with converting the data is if you are losing access to the old system completely.


To add to the don’t do it remarks, depending on the old database type you can also do some union queries to even give people a single pane to the current and old without them as users really knowing the old data is in one place and the new is in Epicor. To them it all looks contiguous. Bringing the historical data over 0/10 do not recommend.


Just curious if keeping the old system up would be an option?
I’ve seen some sites setup read-only access to the old client application or…
access data from the old database via external BAQ’s in Epicor.

Seems like people only need access to the old “stuff” for the first 6 to 12 months after switching systems. So I like keeping the old data separate from the new system if I can.

1 Like

I think that Grant is SaaS, so no External BAQs or clever joins but both are a preferable solution for on-prem users.


Maybe could still dump SaaS data to a local MS SQL database… just to begin? This should allow external BAQ’s and you can always move the data to UD tables in Epicor later if really needed.

His card lists multi-tenant so that’s probably a no go either. Would have to dump historical into UD I guess if he wanted to do any union data for simple reporting. @Mark_Wonsil cloud is the devil lol

Yes… I have suggested getting cloudy at sites with a smaller IT dept or history of employee turnover.
Personally however, I always prefer a room filled with of my own servers.

1 Like

But wait! Cloud is heaven. You DO dump that :poop: into a local SQL database and create a REST API to it. Now our web-based Kinetic client can make a call to that resource and mix it with the data from SaaS.

Post Something GIF

1 Like

Presumably the former ERP system isn’t cloud though . . . I agree, just keep the old system running for reference. Or second choice, extract critical data and DMT it into some UD tables in the cloud.

Yes, we are SaaS. For example, say I bring in 5 years of historical sales from our old system, and 1 year after go-live, I want to see sales of a specific SKU over a the past 6 years. If the historical data is in UD fields, how do we tie that data in Kinetic so that the historical data is also tied with any new transactions we do in Kinetic?

You would need to create BAQs that can union the Epicor and History data together, and create reports or dashboards for the end-users to query the data.

At our company we keep 20 years of historical data separate from Epicor altogether, then have a system that formats the history data to look just like the Epicor tables. We can then run queries and SSRS reports with the history and live Epicor data combined and to the end-user it is basically impossible to tell which data came from where.

Only the active WIP actually made it into Epicor at time of implementation.

1 Like

Leave your old ERP up for 6 months. Then after 6 months just turn it off, telling people that it can be spun back up if needed. You’ll find that a lot of the “need” for access to the old system will quickly go away once people don’t have access to it. :wink:


So now here’s a perfect place for PowerBI or other BI tool. You have static data that you want to report on. Load your history there and add the new stuff as you go along. You have far better reporting tools and not pollute your new system. Again, that’s just me…


We built a terrible set of scripts to painstakingly map everything from Infor Syteline, and after 3-4 months nobody really was using the data, they were accessing the old system instead. We could have just summarized the GL.

Then, we decided having old server was a security risk so we ditched the app and just kept the DB, and within a few months even that was almost never asked for.

Finally we exported the general journal into a spreadsheet, backed up the DB, and shut it down - it’s been 2 years since anyone asked me to run a query.

If I did it again I’d probably save a DB for reference and start with GL account opening values, abd that’s it.

If I could convince anyone.

1 Like

New Years Yes GIF by Hunchback Music