Migrate your ERPNext data

Standard DocTypes with clean CSV export and import support. All mandatory fields are documented in the Data Export UI. We map these 1:1 to the destination's equivalent contact/account objects, preserving territory and group hierarchy as custom properties where needed.

Items include structural data (item group, brand, UOM, barcodes) plus valuation data (valuation method, standard rate). We preserve the full item master including custom fields; image URLs are exported separately and re-linked at the destination.

ERPNext nests BOMs to arbitrary depth. We flatten the BOM tree during extraction and reconstruct it in the destination, mapping routing and workstation definitions as custom fields since most CRMs and ERPs do not have a native BOM object.

Warehouse structure (with bin-level data) and open stock ledger entries are exportable via database query or CSV. We flag whether the destination system uses periodic or perpetual inventory, as this determines whether live stock balances or only transactional history is migrated.

Orders carry line items, taxes, discounts, and delivery schedules. We extract the full order header and all child table rows (packed items, product bundle components) as separate relational CSVs so they can be reassembled in the destination without losing line-level detail.

Sales and Purchase Invoices have a many-to-many relationship with Payments via Payment Entry and Payment Ledger (v14+). We extract both sides and the linking entries, preserving payment status so the destination opens with accurate open/closed invoice states.

ERPNext's Project DocType nests Tasks with assignees, time logs, and milestone dates. We extract the full project hierarchy and flatten it to the destination's equivalent (Tasks as subtasks, or as flat records with a parent-project field). Custom project types and billing rates require explicit field mapping.

Employee master data (department, designation, date of joining, salary structure) plus attendance and leave records are stored across multiple DocTypes. We consolidate these into an Employee profile with compensation history as a linked table, since most non-HR-target destinations cannot represent effective-dated salary rows natively.

Custom fields stored in the Custom Field DocType reference a parent DocType and define fieldtype, options, and mandatory flags. We export the full custom-field registry separately so the destination can receive the field definitions and data simultaneously, avoiding the common issue of importing data before the target fields exist.

Files are stored in the File DocType and reference blob storage (Frappe's private files folder or S3-compatible storage). We export file metadata (filename, URL, doctype reference) and copy the binary blobs, re-uploading them to the destination's storage layer on ingest.

ERPNext Workflow and Document State rules are expressed as DocType records tied to server-side event handlers. These cannot be reliably migrated to non-Frappe platforms because they depend on Frappe's permission architecture and Python hooks. We document the existing workflow state for each migrated document but do not reconstruct automation rules.

Third-party Frappe Apps extend ERPNext with domain-specific DocTypes and server scripts. Without access to the app source code and a compatible Frappe environment, these cannot be migrated portably. We identify installed apps during discovery and flag their DocTypes as out-of-scope explicitly.