Data Migration / Nimex Solutions
Your business history, transferred with structure, validation and control.
Importing a spreadsheet takes an afternoon. A migration is a pipeline: extraction, mapping, cleaning, validation, test imports and reconciliation, run several times before cutover. Nimex runs it with import tooling from our own code, and no invalid row ever becomes a record.
- In our codeimport engine with test runs, per-row savepoints and logs
- How we workseveral test migrations before the real one
The difference
Importing an Excel file is one step of a migration. It is not the migration.
The standard import writes what it is given. A migration decides what should be written, proves it on a test database, and counts the result against the source.
| Question | Importing a spreadsheet | A professional migration |
|---|---|---|
| Where do the rows come from? | Whatever the export produced | Legacy analysis first: which tables, which fields, which copy is trusted, what is history and what is master data |
| What happens to a bad row? | It is written, or the whole file stops | It is flagged with a reason, corrected through an approved mapping or held in an exception report; never written as it came |
| Duplicates and relationships? | Twice is twice | Partner and product normalisation, duplicate rules agreed with you, relationships (supplier, category, parent) resolved before the write |
| Taxes, currencies, units? | Text in a column | Validated against the target configuration: tax codes, currency rates and units mapped and approved |
| How many times? | Once, on production | Several test migrations on a staging database, then the final run in the cutover window |
| How do you know it is right? | Someone looks | Reconciliation table: counts, quantities and balances, source against Odoo, every difference zero or explained |
The tools we migrate with
2,000 product rows, 118 findings, 1,969 records, 31 decisions.
The import engine in our catalogue was built for exactly this: it tests before it writes, runs in the background, logs every row and keeps a failing row from taking the others down. Below, the sample product sheet goes through it.
- TTest before writing
Headers validated against a downloadable template, the canonical header row found even under title rows, duration estimated (8 s + 0.18 s per row). Nothing is written.
In our code - SOne savepoint per row
Each row is processed in its own database savepoint: a failing row is rolled back and logged; the rest is committed. A run is marked Failed when any row errored, with the other rows kept.
In our code - LPersistent log
Draft, In Progress, Finished, Failed; counters for imported, updated, skipped and error rows; row-by-row log text; the uploaded files kept as attachments.
In our code - BBackground job
A detached thread with its own database cursor: no browser timeout on large files, the user keeps working while the import runs.
In our code
Importers in our catalogue read a fixed template; the mapping decisions in the demo are taken in the review with you and applied to the sheet before the run. Importers exist for products and variants, vendor price lists, bills of materials, purchase orders, quotation lines and journal entries; other objects use Odoo's standard import or a migration script written for your source.
Scope
What moves, what needs analysis first, what usually stays behind.
We do not promise to move every field of every system. We agree the scope object by object after the legacy analysis, and the reconciliation covers exactly that scope.
Routinely migrated
- Customers and suppliers with contacts, addresses, tax IDs, payment terms
- Products and variants, categories, units, barcodes, vendor price lists, sales prices
- Bills of materials and routes for manufacturers
- Inventory balances per product, lot and location as an opening inventory
- Accounting opening balances: trial balance, open receivables and payables per partner
- Open sales and purchase orders as the starting documents of the new system
Needs analysis
- Historical invoices and payments: as documents (PDF archive on the partner), as summary entries, or line by line, depending on the legal and reporting need
- Serial numbers and lots with their history
- Fixed assets with depreciation already booked
- Project, timesheet and HR history
- Relationship mapping where the legacy keys are not unique (customer codes reused, products renamed)
Usually stays behind
- Closed documents older than the agreed horizon, kept readable in the old system or as an archive
- Audit logs and user activity of the legacy system
- Configuration that the new architecture replaces: old workflows, custom fields nobody uses
- Anything the source cannot export consistently; we say so in the analysis instead of guessing
Method
Rehearsed on staging until the numbers stop surprising anyone.
A migration is run at least three times: a first test on a sample to learn the data, a full test to measure duration and findings, and a dress rehearsal with the final cutover plan. The real run is the fourth time.
- Legacy analysis
Tables, fields, volumes, which copy is trusted, what is history.
- Extraction
Exports or direct reads, frozen as dated files with row counts.
- Mapping and cleanup
Field mapping, normalisation, duplicate rules, tax, currency and unit mapping.
- Test migrations
Sample, then full, on a staging database; findings reviewed with you.
- Cutover plan
Freeze window, sequence, who approves, how long the old system stays readable.
- Final migration
The rehearsed run in the window, with the exception report closed or accepted.
- Final reconciliation
Counts, quantities and balances signed by the process owners.
Reconciliation
Every object counted on both sides. Every difference zero or explained.
The table is the deliverable of a migration. It compares what the source held against what Odoo holds after the import, for every object in scope, and it is signed before the cutover is declared done.
- Counts for partners and products, quantities for stock, balances for receivables and payables
- Per product and location for stock, per customer for open balances; totals are not enough
- An explained difference is written down with its reason and its owner, like the 31 held products here
Controls
Staging, confidentiality, cutover and rollback, verification.
- 01Staging migrations
Every test run lands on a staging database that mirrors the target configuration; production is touched only in the cutover window.
How we work - 02Security and confidentiality
Source files are exchanged through agreed channels, held on project infrastructure with access limited to the migration team, and deleted at the end as agreed in the contract.
How we work - 03Cutover and rollback
A written sequence with a freeze on the source, a go/no-go after reconciliation, and a fallback: the old system stays readable and the pre-migration backup is kept.
How we work - 04Post-import verification
Spot checks by the owners on real records: a customer's open items, a product's stock per location, a BoM, printed against the old system.
How we work - 05Common challenges
Customer codes reused for different companies, products renamed mid-history, taxes on retired rates, stock counted in a unit the price list does not use, balances that never balanced in the source.
How we work - 06What we do not claim
No universal field-by-field migration of every system, no silent fixes: a row that cannot be resolved stays in the exception report with a name next to it.
How we work