^ Agree with this completely. In any data migration (not just ERPNext) migrating the semi-static data is the easier task. Data such as Customers, Suppliers, Items, Accounts, Addresses.
Migrating transactional data (GL history, AR/AP, Invoices, SO/PO) is always the trickiest part. There is always a ton of metadata and relationships to figure out.
If you can, definitely leave the transactional data behind. Save it somewhere for reporting later.
That said…I often face a challenge with how to handle these cases:
- Invoices that are recorded in the legacy system, but unpaid.
- Purchase Orders that exist in the legacy system, but are not-yet-received?
- Sales Orders in the legacy system, that are not-yet-shipped?
Option 1: Do not migrate the transactions. As those orders reach completion, you record them in the legacy system. The challenge? You have to somehow synchronize the GL & Inventory into your new ERPNext. For example, if you receive and invoice a PO in the legacy system, you have to update the Stock and ledger postings in ERPNext to reflect that.
Option 2: Key into ERPNext Manually. If you have a low volume of Open Orders, it’s better to manually type them into ERPNext, Submit, and process later. By manually typing the data, you don’t have to worry about mapping, enumerations, relationships, and business logic. Yes, it will take time. But how much time, versus developing and writing an electronic Data Migration process?
Option 3: Learn how ERPNext works, and migrate yourself.
I also agree with what @casesolved-co-uk said about creating examples. That’s the best (only?) way to really learn how to perform a manual migration. Create examples, then go inspect the data. See what fields were populated. What was left blank. See how they relate to other tables.
It is extremely time-consuming. You will make mistakes during migration. The only way to catch them? Testing, testing, testing. Try to use your migrated data in the browser. Run reports. Try to Submit and Invoice activity.