# Opening Balances and Data Migration: The ERP Go-Live That Breaks Three Months Later
TL;DR: An ERP go-live almost never fails on the day itself — it fails weeks or months later — typically at the first month-end or quarter-end close — when the ledger won't close, the warehouse doesn't match the system, and nobody can say whether the missing history was ever supposed to be there. The cause is almost never the software. It's a scoping and cutover-date decision nobody wrote down clearly before the first record was migrated.
The pattern: everything looks fine on day one
There's a recognizable pattern in how ERP go-lives go wrong at an operator, EPC contractor or oilfield services company in Angola. On go-live day, the system starts. Users can issue an invoice, raise a requisition, log a warehouse receipt. The project team exhales, and the business's attention moves on to something else.
The problem shows up weeks or months later, when someone tries to do something that requires the migrated data to be complete and correct: closing the month, reconciling a running account with a supplier, physically counting a critical spares warehouse, or answering an audit request about an opening balance. That's the moment someone discovers a customer's balance doesn't match the statement the customer holds, that there are three different item records for the same inventory part, or that the system says there are 40 units of a part in the warehouse when there are physically 12.
None of these are ERP "bugs." They are data migration decisions that were made — or avoided — under deadline pressure, and they only become visible once someone tries to use the data for something that demands accuracy, not just presence.
Migrating balances is not the same as migrating history
The single most important distinction a migration project needs to make — and that most don't make explicitly — is between balances and history.
Opening balances are the numbers the new system needs to hold on the cutover date so that accounting, inventory and running accounts work correctly from that point forward: the balance of every ledger account, the open balance of every customer and supplier, the quantity and value of every item in stock, the net book value of every fixed asset. These are aggregate numbers, generally one per account or item, and they have to close exactly against the legacy system as of the cutover date.
History is the sequence of transactions that produced those balances: every invoice, every warehouse movement, every accounting entry over the last three, five or ten years. History is not required for the new system to function operationally from day one — it's required to answer questions like "why does this customer have this balance," for audit purposes, for multi-year reporting, or for contractual disputes where a sequence of events needs to be proven.
Confusing the two is the origin of a meaningful share of go-live problems. Project teams under calendar pressure correctly decide they are not going to migrate ten years of line-by-line transactional history into the new system — that would be expensive, slow and in most cases operationally unnecessary. The mistake is in how that decision gets communicated and executed: when "we're not migrating history" silently turns into "we're not validating the balances that depend on that history," the project inherits opening balances nobody actually checked against anything, because the "this is out of scope" reasoning got applied to the wrong number. Opening balances are never out of scope. Transactional history can be.
The most defensible practice is to keep the legacy system accessible in read-only mode — even if only internally, with no active usage licenses — for as long as an audit or a contractual dispute might still need to reference a transaction predating the cutover. This costs a fraction of what migrating the full history would cost, and solves the same problem a full migration would solve.
The cutover date decides the rest of the project
Before any technical decision about field mapping or extraction scripts, the project needs to answer a business question: what is the exact cutover date — day, and in some cases hour — at which the legacy system stops being the source of truth and the new system takes over?
That decision determines nearly everything else:
- Which balances have to close. The new system's opening balances have to match the legacy system's closing balance exactly on that date — not a day before, not a day after — because any transaction posted in one system and not the other produces a difference someone will have to find and explain months later.
- What period stays "in transit." Between the data extraction cutoff and the actual go-live there is always a gap — days, sometimes weeks — during which the business keeps operating. Transactions in that window (invoices issued, warehouse receipts, payments) have to be posted manually in both systems, or captured in an explicit "mopping up" process with a named owner and deadline — not left for "someone to sort out later."
- Which multi-year assets and contracts need special handling. A Joint Interest Billing contract or an AFE with accumulated spend mid-fiscal-year cannot simply restart at zero on the cutover date — the accumulated balance has to migrate as an opening balance, even if the history of the transactions that built it stays in the legacy system.
- Which reconciliations must be finished before the decision is made, not after. Choosing a cutover date before knowing whether supplier running accounts actually reconcile is choosing the wrong date — the decision should be conditioned on the real state of the data, not on the project calendar.
An operator with production allocated by partner — a scenario we cover in more depth in upstream production accounting, from wellhead measurement to barrels allocated per partner — feels this particularly acutely: the cutover date has to line up with a production period close, or barrel allocation to each partner ends up split ambiguously between two systems.
The four classic failure modes
1. Duplicated master data
The most common problem isn't missing data — it's too much of it. A customer that exists as three different records because it was entered three times over ten years with small variations in name or tax ID. An inventory item that exists as two separate part numbers because two different people created it in two different modules of the legacy system. A supplier that appears once under its full name and once under an abbreviation.
Every duplicate migrated into the new system doesn't disappear — it multiplies. A customer balance that should live on one record ends up split across two, neither of which reflects the actual position. An inventory report shows two lines for the same bolt, each with a partial quantity. Master data deduplication — customers, suppliers, items, fixed assets — has to happen before extraction into the new system, not after, because untangling duplicates that already have transactions posted on top of them is a far riskier record-merging exercise than simply not duplicating them in the first place.
2. Balances that don't close
A customer or supplier running-account balance in the legacy system is rarely a clean number. It's usually the sum of years of invoices, credit notes, partial payments and manual adjustments — some of which may have been posted incorrectly years ago and never corrected, simply because the aggregate balance "looked" right.
Migrating that aggregate balance without first reconciling it against actual customer and supplier statements means migrating the error, not fixing it. And unlike the legacy system, where a skewed balance could be tolerated for years because nobody looked at it closely, the new system tends to surface the problem fast — because new reconciliation, collections or withholding-tax processes depend on that balance being right from day one. This matters particularly for withholding tax on services, where the tax withheld and declared has to match what's on the books — see what we cover in withholding tax on oilfield services and what the ERP has to calculate.
Reconciling opening balances against independent external sources — bank statements, supplier balance confirmations, a trial balance signed off by the outgoing period's certified accountant — isn't an optional quality step; it's the only mechanism that separates "the number the legacy system said it was" from "the number that's actually true."
3. Inventory that exists in the system and not in the warehouse
This is the most expensive failure mode to discover late, and also the most predictable to avoid. The legacy system says there's a certain quantity of a part in stock; the physical warehouse holds a different quantity. The gap accumulates over years for mundane reasons — unlogged consumption during emergency maintenance, unrecorded returns, transfers between warehouses recorded on only one side.
Migrating the system's quantity without a prior physical count means migrating fiction, not inventory. For operations with critical maintenance spares — the scenario we describe in offshore MRO maintenance, where inventory nobody can see in time can stop a unit — this kind of discrepancy has a direct operational cost: a part the system says is available but physically isn't becomes an unplanned shutdown at the worst possible moment.
There's also a concrete regulatory argument for taking this seriously in Angola: Presidential Decree No. 71/25 created an obligation to submit to the General Tax Administration (AGT) a SAF-T inventory file, with stock quantity and book value as of 31 December of the previous year, by 15 February each year (Art. 24(1)(d)). It applies to every taxpayer, even those with no inventory. The first file, as of 31 December 2025, had its deadline extended by AGT to 15 April 2026 (EY Angola); according to Cegid, AGT also clarified that non-compliance for 2025 will not be penalised. That file requires exactly what a proper migration should already have secured: reconciliation between physical inventory, accounting records and tax position (Cegid). An ERP go-live that inherits an unresolved inventory discrepancy is also inheriting a compliance risk that only becomes visible the following year, when that file has to be filed.
A physical inventory count before migration isn't an internal-audit exercise that can be deferred — it's the one point at which fixing the discrepancy costs an afternoon of counting, rather than months of investigating why the numbers never add up.
4. History nobody validated because it was "out of scope"
The decision not to migrate the complete transactional history is often correct. The mistake is assuming "out of scope for migration" also means "out of scope for validation." If history isn't going to be migrated, but the opening balances derive from that history, someone has to explicitly validate that the sum of the historical transactions — even staying in the legacy system — actually produces the balance being carried into the new system. Without that documented bridge, the opening balance is an assertion, not a verified fact.
This matters particularly for fixed assets with several years of accumulated depreciation, for multi-year contracts, and for any position an external audit will want to reconstruct. An auditor asking for the origin of an opening balance won't accept "that's what the old system said" as an answer — they want to see the reconciliation.
A validation plan that survives deadline pressure
| Phase | What it validates | When it happens |
|---|---|---|
| Master data cleanup | Deduplication of customers, suppliers, items, assets; one record per real-world entity | Before extraction, never after |
| Balance reconciliation | Every opening balance confirmed against an independent external source (bank statement, supplier confirmation, signed trial balance) | Before the cutover date is fixed |
| Physical inventory count | Actual warehouse quantity vs. legacy system quantity, by location | In the weeks immediately before cutover |
| History bridge | Documented proof that the migrated balance is the correct sum of the unmigrated history | Before go-live, archived for audit |
| Transit-period handling | Dual posting or an explicit "mopping up" process for transactions between the data cutoff and the actual go-live | Defined with an owner and deadline before cutover |
| Dry run load | A full migration into a test environment, validated line by line by business owners, not just the technical team | At least one full cycle before the real go-live |
None of these phases are optional if the goal is a system still standing three months after go-live. A frequent mistake in modernization projects is compressing these phases to fit a deadline set before anyone knew the real state of the legacy data — which is backwards: the deadline should depend on what the data requires, not the other way around.
Where systems-level experience helps
Wise Hustlers is developing Enerxia, its ERP for Angola's oil and gas sector — with modules covering upstream, wells, production, projects and contracts, procurement, suppliers, inventory, MRO, maintenance, fleet, logistics, HSE, quality, HR, training, finance, tax and compliance. That breadth of modules is relevant here for a concrete reason: data migration problems rarely stay contained within a single module. An incorrect inventory balance affects reported production cost; a duplicated customer balance affects collections and credit-risk analysis; a mis-migrated asset affects depreciation and tax reporting. Planning the migration module by module, without visibility into how data flows across the whole system, is one reason data problems discovered in one module only surface months later in another.
When the legacy system is old, poorly documented, or a collection of spreadsheets and parallel systems accumulated over years — the scenario covered in more depth in leaving Excel behind: migrating oilfield operations to an ERP without stopping production — legacy modernization work isn't just technical: it's deciding, data point by data point, what's a balance, what's history, and what should never have been labeled "out of scope" in the first place. That's the kind of work done in legacy modernization engagements.
Frequently Asked Questions
How long does an ERP data migration take?
There's no responsible generic number — it depends entirely on the state of the master data, the number of accounts that need reconciling, and how much history an audit requires to stay accessible. A project with clean master data and few unreconciled running accounts is a different exercise from one with ten years of accumulated duplicates. Any vendor quoting a fixed timeline before seeing the real state of the legacy data is guessing, not estimating.
Do we really need to migrate all the transactional history?
Usually not. The most defensible practice is to migrate reconciled opening balances and keep the legacy system accessible in read-only mode for occasional history lookups, rather than replicating years of line-by-line transactions into the new system. The decision not to migrate history is legitimate — what can't happen is using that decision as an excuse not to validate the balances that history produced.
What is the SAF-T inventory file, and why does it matter to a migration project?
It's the electronic file companies in Angola must submit to the AGT every year, by 15 February, with their inventory position — quantity and book value — as of 31 December of the previous year, under Presidential Decree No. 71/25. The first one, as of 31 December 2025, was filed in 2026 with the deadline extended to 15 April. It matters to a data migration because it requires exactly what a good migration project should already have done: reconciling physical inventory against the accounting record before trusting the numbers.
How do you decide the right cutover date?
The cutover date should line up with an already-established accounting or production period close — month-end or quarter-end — and should only be fixed once balance reconciliations and the physical inventory count are complete, not before. Fixing the date first and trying to make the reconciliations fit that deadline is the wrong order of decisions.