ERP data migration and the effort plans overlook

Capital budgets have reopened. After two years in which most enterprise system projects were either postponed or reduced to keeping the lights on, implementation contracts are being signed again — and the plans attached to them carry the same defect they carried in 2019. Somewhere in the second half of the timeline there is a line called data migration, with a duration and a single owner, usually the technical consultant. Data work can be a substantial part of implementation effort and a source of delay. Its share varies by project scope, data quality and migration requirements. Adding consultants does not by itself resolve decisions that require business ownership. Hybrid delivery has made this worse rather than better. The data work used to happen in a room, with the finance manager, the warehouse supervisor and the consultant arguing over a spreadsheet for three days. Distributed across time zones and calendars, the same argument takes five weeks.

The inventory nobody writes down

Ask a project plan what is being migrated and it will typically name five things: customers, suppliers, items, opening balances, and open orders. The real list runs to about twenty-five. Chart of accounts and cost centre structures. Customers and suppliers with tax registrations, payment terms, credit limits and contacts. Items with units of measure, conversions, barcodes, tax codes and default accounts. Price lists and discount structures. Bills of materials and routings. Open receivables and payables, with aging, partial settlements and credit notes. Inventory quantities and values by location, lot and serial number. Fixed assets with cost, accumulated depreciation and remaining life. Open sales orders, purchase orders and goods received not invoiced. Contracts and service agreements. Employee master data, leave balances and end-of-service accruals. Bank accounts and payment file configuration. Intercompany balances. And attachments — the signed orders, delivery notes, customs paperwork and approvals that make a transaction defensible. Each of those is a decision, an extract, a transformation, a load, a reconciliation and a sign-off. Multiply by the number of legal entities and you have the real shape of the work.

Four decisions that set the cost

How much history. Opening balances only, two or three years of transactional detail, or everything. The instinct is everything; the correct answer is almost always balances plus the minimum history the business genuinely uses, with the rest kept in a read-only archive. Statutory retention does not require the old data to live in the new system — it requires you to be able to produce it. Who cleanses. The most expensive sentence in these projects is the consultant will clean the data. Only the business can decide whether two customer records are the same company, whether an item with no movement in four years should exist, or which of three addresses is current. Name owners per object, give them a deadline earlier than they think reasonable, and measure progress weekly. Transform where. Fixing records by hand in spreadsheets feels fast the first time and is ruinous by the fourth, because you will run the load between five and eight times. Build a staging layer with repeatable scripts, so every rerun costs hours rather than weeks and every correction is applied to the source of truth rather than to a copy. What reconciled means. Define it before the first load: trial balance agreement to the penny, receivable and payable aging agreement by bucket and by counterparty, inventory quantity and value by location, asset register agreement by class, counts of open documents, and a named person who signs. Without that definition, the load completed with three hundred errors we will fix later becomes the project's official status.

Reconciliation is a deliverable, not an activity

Build the reconciliation pack before the first mock load, and use the same pack every time. It should work at three levels: record counts per object, control totals per object, and traced samples — twenty documents per object followed end to end, chosen to include the awkward cases rather than the clean ones. The awkward cases are predictable. Partially settled invoices. Credit notes applied against multiple invoices. Customer advances and supplier prepayments. Retentions. Foreign currency balances and their revaluation basis. Goods received but not invoiced. Negative stock. Serial and lot tracked items with split quantities. Intercompany balances that do not agree between entities even in the legacy system — a problem you must fix before migration, because migrating a disagreement makes it permanent and visible.

Rehearse three times, and time it

Mock load one tests shape: do the structures map, do the mandatory fields exist, what proportion fails validation. Mock load two tests volume and duration with full data. Mock load three is a dress rehearsal — the real cutover runbook, the real people, executed in the real sequence, with a stopwatch. That stopwatch matters more than anything else in the plan, because the cutover window is fixed by the business calendar and not by the technology. If the final load takes nineteen hours and your window is fourteen, you need to know in March, not on the Thursday before go-live. Record durations for every step, including the ones nobody counts: the final stock count, the freeze on transactions in the legacy system, the reconciliation itself, and the approval to open the new system for users.

Practical Guidance for Migration Planning Assessment

• Write the full object inventory with an owner, a history decision and a reconciliation definition for each.
• Estimate data work explicitly from your inventory, quality and reconciliation requirements, and name business owners alongside the integrator. Do not assume a universal effort percentage.
• Choose balances plus minimum history, and fund a read-only archive for the rest.
• Build a repeatable staging and transformation layer instead of editing spreadsheets by hand.
• Create the reconciliation pack before the first load and run it identically every time.
• Rehearse the cutover three times and time every step, then compare against your actual window.
• Fix intercompany and aging disagreements in the legacy system first, so you do not migrate a dispute.
• Decide the attachment strategy early — migrate, link, or archive — because it drives storage, search and audit answers.

The Regional Angle

Three issues arrive on almost every regional project, and the first can stop a programme before configuration starts. A large share of mid-market businesses here run on software supplied by a local developer, on a version the vendor no longer supports, or on a system whose original implementer has ceased trading. Getting your own data out is a real project with a commercial dimension: the database password may be held by a former employee, the export utilities may not work on that release, the documentation may not exist, and the incumbent partner — who is about to lose the account — may want a fee to help. The leverage is entirely theirs at exactly the wrong moment. Do the extraction before you sign the implementation contract: obtain a full database backup, restore it into an environment you control, confirm you can read every table you need, and only then commit to a timeline. A programme that begins with successful extraction has removed its single largest unknown. The second is master data identity. Across the region the same counterparty routinely exists under four records: the trade licence name, the trading name, an Arabic name, and a shortened version typed by whoever raised the first invoice. Historically there was no reliable unique identifier, which is why deduplication here is harder than it is elsewhere. Tax registration changed that — the registration number is the first genuinely unique customer and supplier key most regional businesses have ever had. Deduplicate against it, make it a required field for anyone you invoice or pay, and reconcile your master file against the public verification service. The exercise pays for itself twice: once in migration, and again when tax authorities begin matching your filings against your counterparties' filings. The third is the employee data everyone underestimates. End-of-service gratuity and leave balances are not simple numbers to carry across; they are calculations whose basis differs by country, by entity and sometimes by contract vintage. Migrating an accrued balance without migrating the basis — original joining date, service transferred from another group company, last basic salary, unpaid leave, prior settlements — leaves you with a liability you can display and never recompute. The first time an employee disputes a settlement, or an auditor asks how the provision was derived, the answer will be that it came over from the old system. Migrate the inputs, recalculate in the new system, and reconcile the result against the legacy figure employee by employee before go-live.

The objection worth taking seriously

The strongest objection is that this is an argument for bigger budgets and longer timelines dressed up as rigour. Gold-plated migrations delay go-live, and delay costs more than imperfect data. Most migrated history is never queried again — organisations that moved seven years of transactions routinely find that nobody opens anything older than the current year. The pragmatic answer is balances only, a fast go-live, and the legacy system kept available read-only. Insisting on twenty-five reconciled objects and three dress rehearsals is how a nine-month project becomes an eighteen-month one. That is largely right, and the balances-plus-archive approach is the recommendation here too. An unsupported fixed effort percentage can become an excuse rather than a plan. But the claim is about owned decisions and rehearsed execution, not about volume. The minimal migration needs exactly the same discipline as the maximal one, because the failure mode is not missing history — it is an opening balance that cannot be tied out, a receivables ledger that does not age correctly, a stock valuation the auditor will not accept, and a first month-end close that takes three weeks. Organisations that go live and cannot close have not saved time; they have moved the cost into a period when it is more expensive and far more visible. And the read-only archive is not free either: it needs a licence, an access path, a retention decision and someone able to answer a tax query from it in five years, by which point the person who knew the old system will have left. Plan the cheap migration properly rather than assuming cheap means simple.

Common Questions

How much history should we migrate?

Opening balances, open items, and the current plus prior year where the business genuinely uses comparatives. Archive the rest and test that you can retrieve from it.

Can the integrator own data migration?

They can own extraction, transformation and loading. They cannot own cleansing decisions or reconciliation sign-off, and pretending otherwise is the most common cause of overrun.

How many mock loads are enough?

Three, with the last one timed as a full dress rehearsal. If the third still produces surprises, you are not ready for a date.

What should we expect over the next twelve months?

Expect tax digitisation to raise the stakes on master data quality — the next phase of electronic invoicing in Saudi Arabia requires system-to-system integration, and a counterparty file full of duplicates will fail in public rather than privately. Expect cloud suites to keep improving migration tooling while reconciliation stays stubbornly manual. Expect better partners to start pricing data work as a separate, explicitly staffed workstream, which is a sign of maturity rather than of greed. And expect a visible crop of go-live-and-cannot-close stories this year, as programmes are compressed to land inside a single budget cycle.

---

Migration Planning Assessment — we build the object inventory, prove extraction from your incumbent system before you commit to a date, and define what reconciled means while it is still cheap to answer.