we are starting planning to import in ERPNExt our old ERP Database.
Just to be clear old ERP Sofwtare is Not ERPNExt but totaly different software that we want dismiss and start using powerful ERPNext.
On that old Relational Database we have several tables like Items , Customers, Suppliers and mny tohers that we want import populating the ERPNext DocTypes. Of course, tables are connected each other by entity relationships related keys.
To import single tables I can see that valuable data import tool is present , but how to proceed to import tables
that are connected each other by key constraint? In the data import tool template is not possible to use old ID we have in the origin Database, as value for “name” DocType field, so how can we import tables mantaining previous DB relations between them (primary/foreign keys)?
I was looking around for a detailed guide/procedure to use to manage this importing and
I feel we need it because the old ERP Database has a quite complex structure. How do you suggest to proceed?
Hi @italjapan! If your old ERP is not ERPNext, I suggest you set up beginning balances instead of importing everything. What most company does is set a cut off date and calculate beginning balances to setup to ERPNext. If in the event that past data needs to be recheck, they will retain old ERP for this purpose. This way, it won’t be too complicated to import. The suggestions above are the ways to do it though but would be timely and needs careful attention to balance accounts.
Because ERPNext is free and opensource, it doesn’t have much overheads for hosting one more instance.
There is one more approach, setting up 2 ERPNext instances, one is for reference only where old data is hacked into and other is production setup as mentioned by @creamdory
I came across a company who had invoices of past 3 years, these invoices must be in a database because their customers may return goods any time even after 6 months or a year. Due to some reason we couldn’t maintain old erp to keep track of old data. So we settled for 2 instances. This approach keeps the production server up to date and reference server is never updated keeping the hacks intact.
After 2 years on ERPNext there will be least dependence on old system and obsolete reference server can be deleted.
If in your case you could maintain old system running for reference that will solve the problem.
Thanks for your answer , very kind of you.
Browsing the code I see this useful example line code:
rename_doc(“Sales Invoice”, si.name, voucher_no, force=True)
From your example I can understand that each import and each table will have it’s own specific methodology to apply in order to have an import that make sense. So having quite complex tables relationship , several specific ad-hoc script will be required to move piece of the old DB o the new era Erpnext.