ERPNext data migration means moving your master data and opening balances — not a decade of transaction history — from a legacy system into a clean, reconciled ERPNext instance on a fixed cut-over date. The principles are the same whether your source is Tally, SAP, a spreadsheet, or a custom database: decide what carries forward, map every field, import through the Data Import tool, post opening balances correctly, then reconcile before the first live transaction.
Short answer
ERPNext data migration is the structured transfer of masters (accounts, customers, suppliers, items) and opening balances into ERPNext, using the built-in Data Import tool for CSV records and dedicated tools for opening stock and open invoices. Import history is left in the old system as a read-only archive. A clean migration is defined by a mapped cut-over date and a matched trial balance — not by how much data you move.
I am Manoj, an ERPNext implementation consultant at Mith Tech in Bengaluru, and I have run migrations off Tally, SAP, QuickBooks, and homegrown Excel systems for Indian SMBs. The mechanics are rarely the hard part. The honest truth is that most failed migrations fail on discipline — a fuzzy cut-over date and unmapped ledgers — not on any missing feature in the tool.
What is ERPNext data migration?
ERPNext data migration is the process of transferring the data your business needs to operate — chart of accounts, customer and supplier masters, item masters, and financial opening balances — from an existing system into ERPNext as of a chosen cut-over date. Historical transaction detail stays behind. The goal is a clean, reconciled starting point, not a full-history copy.
Every source system is different, but the destination shape is identical. ERPNext stores data in doctypes — structured tables with parent records and child tables — and almost all of them accept a CSV or Excel import. That uniformity is why the same five-stage method works regardless of whether you are leaving Tally, SAP, Zoho, or a stack of spreadsheets. ERPNext is free and open source under GPLv3, so you can spin up an unlimited number of test instances to rehearse the migration at no licence cost.
Skimmable summary: Migration moves masters and opening balances into ERPNext on a cut-over date; history stays in the old system.
What data should you migrate — and what should you leave behind?
Masters and open items migrate; closed history does not. Bring forward your chart of accounts, party masters, item masters, opening stock, and any unpaid invoices as on the cut-over date. Leave every paid invoice, old payment voucher, and historical stock movement in the source system, which remains available as a read-only archive for audits and lookups.
The most common mistake I see is trying to import everything. A ten-year voucher history bloats the new database, slows reports, and adds no operational value — nobody searches for a 2019 receipt inside a live ERP. The clean split looks like this:
| Data type | Migrate to ERPNext | Keep in source (archive) |
|---|---|---|
| Chart of accounts | Yes — ledger and group masters | — |
| Customers / suppliers | Yes — with GSTIN, PAN, addresses | — |
| Items | Yes — with HSN/SAC, UOM, tax category | — |
| Opening balances | Yes — as on cut-over date | — |
| Open (unpaid) invoices | Yes — outstanding only | Paid invoices stay |
| Stock | Opening quantity + valuation | Old movement history |
| Closed transactions | No | Yes — read-only |
This keeps the opening-balance audit simple and your ERPNext instance fast.
Skimmable summary: Migrate masters, opening balances, and open invoices; archive all closed, paid history in the old system.
How does the ERPNext Data Import tool work?
The Data Import tool imports records from a CSV or Excel file into any doctype, in one of two modes: insert new records or update existing ones. Download the template for the target doctype, fill it, attach it, let the tool validate row by row, map any renamed columns, then run the import. Mandatory fields are flagged in the template so nothing critical is missed.
Here is the reliable sequence I follow for each doctype.
Download the template
Open Data Import, choose the document type (for example Customer or Item), select Insert New Records, and download the template. Mandatory fields are marked; conditional fields carry an info note.
Fill and clean the data
Populate the template in Excel. Clean as you go — trim stray spaces, standardise capitalisation, and save as UTF-8 CSV so non-English characters do not corrupt. Leave the ID column blank when inserting new records.
Attach and validate
Upload the file. The tool validates the sheet and lists warnings by row and column before anything is written. Fix the flagged rows and re-attach until the preview is clean.
Map columns
If you renamed or added columns, use map columns to align each one to the correct ERPNext field. Templates from the tool map automatically — always verify anyway.
Import in sensible batches
Import a few thousand records at a time rather than tens of thousands in one shot; large single imports slow the system. For submittable documents such as invoices, decide whether to enable Submit After Import.
Import in dependency order
Import masters before transactions. Accounts and parties must exist before you load invoices against them; items must exist before stock. Skip the order and the tool rejects rows for missing links.
Skimmable summary: Download template, fill and clean to UTF-8 CSV, validate, map columns, import in batches — masters before transactions.
How do you map legacy fields to ERPNext?
Field mapping is the exercise of matching each concept in the old system to its ERPNext equivalent before any import runs. Legacy account groups map to ERPNext account types; legacy party ledgers split into separate Customer and Supplier masters; legacy stock items map to Item records with HSN codes. Get the account-type mapping right and everything downstream reconciles.
Mapping is conceptual, not mechanical, so it needs a person who understands both systems. A worked example for the common fields:
| Source concept | ERPNext target | Watch out for |
|---|---|---|
| Ledger under "Sundry Debtors" | Customer master + Receivable account | One debtor ledger becomes one Customer |
| Ledger under "Sundry Creditors" | Supplier master + Payable account | Same party may be both customer and supplier |
| Sales / purchase tax ledgers | Tax accounts + tax templates | Consolidate duplicate GST heads into one set |
| Stock item | Item master | Assign an explicit item code and HSN/SAC |
| Bank / cash ledger | Account (type Bank / Cash) | Reconcile to statement at cut-over |
Two mapping errors cause most rework. First, duplicate tax heads — legacy systems often carry several CGST or SGST ledgers across registrations, while ERPNext expects one clean set per company. Second, relying on item names as keys; assign explicit item codes so near-identical names are not merged.
Skimmable summary: Map legacy account groups to ERPNext account types and consolidate duplicate tax heads before importing anything.
How do you bring in opening balances?
Opening balances enter ERPNext through three separate tools, one per balance category. Stock in hand goes in via a Stock Reconciliation with purpose set to Opening Stock. Unpaid customer and supplier invoices go in via the Opening Invoice Creation Tool. Every remaining ledger balance — banks, cash, capital, loans, fixed assets — goes in through a single Journal Entry against a Temporary Opening account.
Keeping these three paths distinct is what makes the books reconcile cleanly.
Post opening stock
Use Stock Reconciliation with purpose Opening Stock to set item quantities and valuation rates as on the cut-over date. This aligns the Stock Ledger with the general ledger.
Create open invoices
Use the Opening Invoice Creation Tool for outstanding debtors and creditors. Choosing Sales or Purchase generates the matching invoice type; enabling Create Missing Party auto-creates any customer or supplier not yet present.
Post the remaining ledger
Enter all other closing balances from the old system as a Journal Entry dated to the cut-over, booked against the Temporary Opening account so debits and credits net to zero.
Clear the temporary account
Once every category is posted, the Temporary Opening account balance should be nil. A non-zero balance means a category is missing or double-counted — find it before proceeding.
Start at a financial period boundary
Set your cut-over to the first day of a financial month, ideally the start of a financial year. Mid-month cut-overs force you to split GST returns between two systems and turn reconciliation into a monthly headache.
Skimmable summary: Opening stock via Stock Reconciliation, open invoices via the Opening Invoice Creation Tool, everything else via one Journal Entry against Temporary Opening.
How do you validate a migration before go-live?
Validation means proving, before any live transaction, that ERPNext holds the same financial position as the source system on the cut-over date. Run a full set of reconciliations: trial balance, debtor and creditor ageing, bank balances, tax ledgers, and stock value. Every one should match line by line, and any difference beyond rounding must be traced to a specific cause.
Work through this checklist on the staging instance first, then repeat on production after the real import:
- Trial Balance — ERPNext's trial balance should match the source system account by account as on the cut-over date. Investigate any gap over a rupee.
- Receivables ageing — total outstanding and invoice-level detail should match; a mismatch usually means a missing opening invoice.
- Payables ageing — same check for suppliers.
- Bank and cash — reconcile each account to its statement; exports are a frequent source of rounding drift.
- Tax ledgers — input and output GST balances should tie to the source system's tax position.
- Stock value — the Stock Balance total should equal the stock-in-hand figure in the trial balance.
A migration is not done when the data is imported. It is done when the trial balance matches and the temporary opening account reads zero.
Skimmable summary: Reconcile trial balance, ageing, bank, tax, and stock against the source system before issuing a single live transaction.
How should you plan the cut-over and rehearse the whole thing?
Cut-over planning means rehearsing the entire migration on a throwaway staging instance until it runs clean, then executing the real import in a single tight window at the period boundary. Because ERPNext is free to install, you can stand up as many staging copies as you need to test imports, mappings, and opening balances without touching production or paying anything.
The rehearsal is not optional. A dry run on staging surfaces the duplicate ledgers, missing HSN codes, and mapping gaps that would otherwise appear on go-live day. Once staging reconciles perfectly, freeze new entries in the old system, run the production import, post opening balances, reconcile again, and only then start live transactions. Run both systems in parallel for a short verification window so finance can spot anything the reports missed. ERPNext runs on the Frappe framework, which keeps custom fields and scripts portable between your staging and production instances.
Skimmable summary: Rehearse the full migration on a free staging instance, freeze the old system, import at the period boundary, reconcile, then go live.
Source-specific migration guides
The five-stage method above applies to any source, but each system has its own export quirks and traps. For a step-by-step walkthrough tailored to your current system, use the guides below.
Tally to ERPNext
Export masters and balances from Tally, map ledger groups to account types, and reconcile GST heads. See Tally to ERPNext migration.
SAP to ERPNext
Extract from SAP tables, rationalise a large chart of accounts, and re-map cost centres. See SAP to ERPNext migration.
Budgeting the project
Data complexity and entity count drive the effort. See ERPNext implementation cost in India for a transparent breakdown.
Skimmable summary: The same method applies everywhere; follow the source-specific guide for your system's export quirks.
Frequently asked questions
What data actually needs to migrate to ERPNext?
Masters and opening balances need to migrate: chart of accounts, customer and supplier masters, item masters, opening stock, and any unpaid invoices as on the cut-over date. Closed, paid transactions do not — they stay in the source system as a read-only archive you can still reference during audits.
Can the ERPNext Data Import tool handle all my records at once?
The tool has no hard row limit, but importing a few thousand records per batch is recommended; very large single imports slow the system. Split big datasets by doctype and batch, import masters before transactions, and always save files as UTF-8 CSV so special characters do not corrupt on the way in.
How are opening balances posted in ERPNext?
Opening balances use three tools. Stock in hand is posted through a Stock Reconciliation with purpose Opening Stock. Outstanding customer and supplier invoices go through the Opening Invoice Creation Tool. All other ledger balances are entered as one Journal Entry against a Temporary Opening account, which should net to zero once everything is posted.
Will my old system's data be deleted after migration?
No. Migration copies data into ERPNext; it does not touch the source system. Your existing installation and its full history remain intact and available as a read-only archive. You simply stop posting new transactions there and start them in ERPNext from the cut-over date onward.
How do I know the migration was successful?
Success is measured by reconciliation, not by import completion. Export a trial balance from ERPNext as on the cut-over date and confirm it matches the source system account by account. Then verify debtor and creditor ageing, bank balances, tax ledgers, and stock value. When all of them match, the migration is complete.
Do I need a partner, or can I migrate myself?
ERPNext ships the Data Import tool and opening-balance tools for teams comfortable with ledger mapping and reconciliation, so a capable in-house finance and IT team can do it. Most SMBs bring in a partner because opening-balance errors are expensive to unwind after go-live, and an experienced eye catches mapping mistakes before they reach the books.
About the author
I am Manoj, an ERPNext implementation consultant at Mith Tech, an independent open-source ERPNext and Frappe studio based in Bengaluru. I work with Indian SMBs on migrations, GST compliance, and go-live support, and I write these guides from real implementation experience rather than vendor marketing.
Planning an ERPNext migration?
We handle the full migration — export, mapping, import, opening balances, reconciliation, and go-live support — so your team does not learn it by trial and error on production.