Data cut-over: trial loads and reconciling to the taka

Decide what to migrate, and what not to

The instinct is to bring everything: all customers since 2012, every invoice, five years of stock movements. Resist it. Every extra year you migrate multiplies cost and risk for data nobody will open in Odoo. The standard approach is:

• Masters: active customers, vendors, products, BOMs, employees, chart of accounts, fixed assets.
• Opening balances at the cut-over date: trial balance, open receivables and payables (per invoice), stock quantities and values, and assets at net book value.
• Open documents: purchase orders not yet received, sales orders not yet delivered, open LCs.
• History: archived, read-only, in the old system or an export. It's available if auditors ask, but not migrated.

Write this decision down and get the finance head to sign it. It stops "can we also bring last year's sales?" arriving two days before go-live.

Clean before you map

Data cleaning is business work, not IT work, and it takes longer than anyone budgets for. In Bangladesh projects, the recurring problems are:

• The same customer entered three ways ("ABC Garments Ltd", "ABC Garments Limited", "A.B.C. Garments").
• Vendors without TIN or TDS category, so withholding can't be configured correctly.
• Customers without BIN, so Mushak 6.3 can't be printed correctly.
• Products with inconsistent units: yards in purchase, metres in stock, pieces in sales, with no conversion recorded.
• Opening stock taken from the old system instead of a count.

The data migration checklist has all 40 cleaning and loading tasks, plus a sheet of Bangladesh-specific fields to capture.

Opening stock comes from a physical count

This is the rule most often broken and most often regretted. If you load opening stock from Tally or Excel, you're loading every past error into your new system, and the warehouse will spend three months doing adjustments. Instead:

1. Count everything physically, by location, as close to cut-over as possible (usually the Thursday–Friday before going live).
2. Compare the count with the old system and investigate the big differences.
3. Get finance approval to write off the differences in the old system, so its closing value equals the count.
4. Load the counted quantities with unit costs into Odoo.
5. Check: Odoo stock valuation = physical count value = old system closing stock (after the write-off) = the stock account in the opening trial balance.

Load order

Dependencies decide the order. Load in this sequence, and never load a later object before the one it depends on is verified:

Company settings → chart of accounts and taxes → partners (customers, vendors) → products and categories → BOMs → opening stock → opening AR/AP → assets → open documents.

Trial loads: rehearse twice

Run at least two full trial loads before the real one:

• Trial load #1 (before UAT cycle 1) finds mapping errors, missing fields and bad data. Expect a long error list.
• Trial load #2 (before UAT cycle 2) is run by the actual cut-over team, timed per object, following the written runbook. Its timing tells you whether the cut-over fits in a weekend.

Both loads feed UAT, which means testers are also checking the data, not just the configuration.

Reconcile to the taka

After every load, reconcile counts and sums against the source. "Close enough" is not a reconciliation.

Then have each data owner spot-check 20 random records against the source. Totals can match while individual records are wrong, for example two customers' balances swapped.

The freeze

From the final snapshot until Odoo is live, nobody enters transactions in the old system. Announce the freeze window to operations at least two weeks ahead. Anything that happens during the freeze (an urgent delivery, a payment) is recorded on paper and entered into Odoo as the first transaction after go-live. Plan for it rather than pretending it won't happen.

Go deeper: Data migration checklist for Odoo in Bangladesh and Excel → Odoo migration checklist.