Compiere, ADempiere, Tally, QuickBooks or any ERP → iDempiere — reconciled to the last rupee.
Two related but distinct jobs: moving your business onto iDempiere from a legacy system, or carrying an existing installation forward to the latest release. Both hinge on the same discipline — clean data in, reconciled balances, and a rollback point if the weekend goes sideways.
The failure mode of every ERP migration is the same: opening balances that do not tie to the old trial balance, and stock that does not match the old warehouse report. We treat the reconciliation as the deliverable and the data load as the means to it.
Partners, products, accounts and tax loaded and validated before a single balance moves.
A signed reconciliation pack against your trial balance and stock report.
For upgrades, a tested restore point so a bad Sunday never becomes a bad Monday.
Our default is deliberately conservative. We migrate master data and open items — unpaid invoices, open orders, stock on hand and opening balances posted into the ledger — rather than years of closed transactions. History stays in the legacy system, read-only for lookups. That is cheaper, faster, and keeps the new database lean.
Whether you are leaving Compiere or ADempiere, growing out of Tally or QuickBooks, or retiring the spreadsheets, the strategy is the same shape. The effort sits in the mapping and the reconciliation, not the loading.
We load in dependency order. Business Partners, Products, the chart of accounts and Accounting Schema, tax rates and price lists come first, because everything else references them. Only once master data validates do we bring across open items: unpaid customer and supplier invoices, unshipped orders, and stock on hand by warehouse and locator. Closed history is left behind.
The cut-off is a business decision as much as a technical one. We agree a freeze date, a quiet window at month-end where possible, and exactly which documents are "open" at that instant. For the load we use iDempiere's built-in Import Loader and the standard import windows for well-structured sources, and purpose-built ETL — SQL and scripted transforms — where the source is messy, as Tally exports and old spreadsheets usually are. Every field is traced in a mapping specification first.
Sources we move from. Compiere and ADempiere (the closest lineage — schema is familiar but not identical), Tally, QuickBooks, Excel and Google Sheets, and bespoke in-house databases. Each has its own quirks; none is a straight copy.
The honest bit. We almost never migrate full transactional history. It bloats PostgreSQL, rarely earns its keep, and complicates reconciliation. The old system stays available read-only. Where a statutory or reporting need is real, we scope a targeted history load as a separate exercise.
Reconciliation runs alongside the load, not after it. Loaded AR and AP are tied back to the source aged-debt reports; opening balances are checked against the closing trial balance; stock valuation is matched to the old inventory report. Discrepancies are chased down and explained before anyone signs. We then run a parallel run where practical — the same transactions entered in both systems for a period — so finance can compare outputs on live data before the legacy system is switched off. Only after sign-off do we cut over.
A version upgrade is a different animal from a migration. The data already lives in iDempiere's schema; the risk is in the Application Dictionary changes, the community migration scripts, and whatever custom plugins you have layered on top.
Each iDempiere release ships a set of migration scripts that alter the database and update the Application Dictionary — new columns, windows, processes and reference data. We run a dictionary diff between your current version and the target to see exactly what changes, and to flag where your customisations sit on top of tables the release is about to touch. That diff is what turns an upgrade from a gamble into a plan.
Your OSGi plugins, callouts and model validators are compiled and tested against the target release before anything touches production. API changes between versions do break plugins; finding that on a test instance is routine, finding it on Monday morning is a crisis. We migrate a copy of the production PostgreSQL database first, apply the scripts, and run the plugin regression suite against real data volumes.
Rollback plan. Before the production upgrade we take a full, verified database backup and a snapshot of the application deployment. If a showstopper appears mid-cutover, we restore to the known-good point and reschedule — the business is never stranded on a half-upgraded system.
2-Pack for portability. Where customisations need to move between environments as part of the upgrade, we package them as 2-Pack archives so dev, test and production stay in step rather than drifting apart.
The sequence is deliberately unglamorous: clone production to a test instance, apply the migration scripts, resolve any dictionary conflicts, rebuild and regression-test every plugin, then have your team run a scripted pass over the critical documents — Sales Orders, Shipments, Invoices and the month-end posting into the Accounting Schema. Only when the test upgrade is clean and repeatable do we schedule the production window, and even then with the rollback point ready.
The figures below are indicative ranges for the data-migration workstream from projects of similar shape — not fixed quotes, and not the whole project. Effort scales with data volume and, above all, data quality.
| Source system | Typical migration effort | Main risk to manage |
|---|---|---|
| Compiere | 3–6 weeks | Schema is close but not identical; old customisations and dictionary drift must be reconciled, not assumed compatible |
| ADempiere | 3–6 weeks | Shared lineage helps, but version gaps and forked custom tables need careful diffing before any assumption of a clean lift |
| Tally | 4–8 weeks | Flat, India-centric exports with loose master data; heavy cleansing and account mapping before balances will reconcile |
| QuickBooks | 4–7 weeks | Simple ledger model with little inventory depth; the gap is building the item, warehouse and tax structure iDempiere expects |
| Spreadsheets | 3–8 weeks | No enforced integrity — duplicates, typos and inconsistent codes; the range is driven almost entirely by how dirty the sheets are |
| Legacy in-house system | 6–12 weeks | Undocumented schema and business rules; time goes into reverse-engineering and validating the source before mapping can start |
| Existing iDempiere (version upgrade) | 2–5 weeks | Migration-script conflicts and plugin regressions; the data is fine, the customisations are where it bites |
Note. Ranges assume a single entity of moderate size and exclude configuration, UAT and training, which are scoped separately. A messy source or high transaction volume pushes effort to the top of the range. We confirm your figure after a short data-profiling exercise.
Four well-worn routes into iDempiere — each with templates, load tooling and a reconciliation pack at the end.
Shared lineage makes this our most structured path — masters, open transactions and balances mapped table-by-table, with customizations re-homed as plugins.
The ADempiere Lineage 02Structured templates and load tooling take you from ledgers and spreadsheets to a full ERP — staged, validated and reconciled against your trial balance.
Plan Your Migration 03Any old version to the latest release — customizations, plugins and data carried forward with full regression testing and zero surprises at go-live.
See Upgrade Stories 04Scoped extraction from closed systems — field-mapping workshops, staged loads and a reconciliation pack, with the old database kept read-only for lookups.
See a Migration DemoThe same backbone serves both a new migration and a version upgrade — the difference is what "source" means and how much of it is data versus dictionary.
We profile the source data or, for an upgrade, diff the Application Dictionary. Row counts, duplicate rates, missing tax codes, orphaned references and customisation footprint are measured, not guessed. This is what turns the indicative range into a firm estimate.
We agree the freeze date and exactly which documents count as open, then write the field-by-field mapping specification. For upgrades, this stage identifies migration-script conflicts and the plugins that need rework before production is touched.
Partners, products, accounts, tax and price lists are loaded in dependency order using the Import Loader or custom ETL, then validated. Nothing referencing master data proceeds until master data is clean.
Open invoices, orders, Storage On Hand and opening balances are loaded and reconciled against the trial balance and stock report. Every variance is explained and resolved, and the reconciliation pack is prepared for sign-off.
Where practical we run in parallel so finance can compare live outputs, then cut over on a rehearsed weekend. For upgrades, the tested rollback point stands ready until the first clean close confirms the move.
A field-by-field document tracing every source column to its iDempiere target, with the transform rules and the cut-off definition agreed in writing.
Loaded AR, AP, opening balances and stock tied back to your source trial balance and inventory report, with every variance explained and signed.
The SQL, transform scripts and Import Loader templates used for the load, handed over so a repeat run — or the next entity — is repeatable, not improvised.
The side-by-side comparison from the parallel period — documents, postings and reports from both systems — so finance can see the numbers agree before cutover.
For upgrades, the verified database backup, deployment snapshot and the documented restore procedure — the escape hatch that makes the production window safe.
Formal acceptance of the reconciliation and parallel run — the audit trail that lets finance, operations and the sponsor all commit to switching the old system off.
"Your balances are either right or they are wrong — there is no 'mostly migrated'. We reconcile to the last rupee before anyone touches production."
Leave the legacy behind.
Keep every number that matters — reconciled and signed off.
Masters, open transactions and opening balances land in iDempiere with a reconciliation pack your auditors will actually enjoy reading.
Trusted worldwide for end-to-end iDempiere services — the best in the industry at what we do. Send us a sample extract or point us at your current iDempiere version, and we will size the migration or upgrade against real data rather than a guess. No obligation.
