Preparing source data for an ERP migration

When a growing business moves from a small-business accounting platform into an ERP environment, the change is structural rather than cosmetic. The destination expects richer master data, stricter relationships between records, and dimensions the source system never required. Preparing for that shift early is what keeps the data workstream from becoming the critical path of the whole implementation.

This article is educational and forward-looking. ERP routes are a direction of development for Ledrix rather than a universally available capability — see platform direction for current context.

Why source-data readiness drives effort, cost and timing

Implementation effort is usually estimated from configuration scope: modules, workflows, approvals, reporting. Data is often treated as a task at the end. In practice the condition of the source data determines how much of that configuration can proceed on schedule, because design decisions depend on knowing what the data looks like.

Poor readiness shows up as rework: loads repeated because master data was incomplete, design revisited because the source turned out not to support a required dimension, and testing delayed because the test data does not resemble reality. Each of those consumes implementation-partner time, which is the most expensive time in the project.

Data extraction is not data readiness

Extraction is the ability to get records out of the source system in a usable format. It is a prerequisite, and it is usually the easy part. Readiness is a different question: are those records complete, consistent, deduplicated, correctly classified, and structured so that they can be mapped into the destination's model without a series of judgement calls made under load-window pressure?

A useful test: if the extract were loaded tomorrow, how many questions would the implementation partner have to ask before proceeding? Every one of those questions is a readiness gap, and each is cheaper to close now than during a load.

Master data comes first

Customers, suppliers, products and services, the chart of accounts, tax codes and payment terms are the records everything else depends on. Duplicates, inconsistent naming and missing attributes become considerably more expensive once they exist inside an ERP, because they propagate into transactions, approvals and reporting.

Customers and suppliers

• Deduplicate on a defined rule — trading name, ABN or account code — and record which record survives
• Standardise naming conventions before loading, not afterwards
• Complete tax registration, payment terms, currency and default account attributes
• Decide which inactive records are archived in the legacy system rather than migrated
• Confirm how parent-and-branch or multi-site relationships will be represented

Products, services and the chart of accounts

ERP systems typically introduce concepts the source did not have: posting groups, item categories, cost centres, dimensions, locations or entity structures. These are not presentation choices — they drive posting behaviour and reporting. Someone has to decide how existing records map into them, and that decision benefits enormously from being made and reviewed before a load rather than during one.

Tax codes and payment terms

Tax code mapping deserves specific attention because it is both mechanical and consequential. List the codes actually in use in the source — not the codes available — and map each to its destination equivalent, noting any that have no clean counterpart. The same applies to payment terms, which often exist as free text in a smaller system and as structured records in an ERP.

Decide the historical-data strategy early

Full transactional history rarely transfers cleanly into an ERP, because the destination's posting rules and data model differ from the source's. A common approach is opening balances, plus open items, plus a defined period of comparative detail, with the legacy system retained as the reference for anything older.

Whatever the approach, it should be a documented decision with the reporting consequences understood — how comparatives will be produced, how long the legacy system stays accessible, who retains that access, and what happens to source documents and attachments. A history strategy discovered at the end of a project is a reporting problem in the following year.

Establish ownership of mapping and transformation

Mapping decisions sit awkwardly between parties. The implementation partner knows what the destination expects. The business knows what the data means. The accounting practice often knows why a historical treatment exists. If ownership is not explicit, mapping tends to default to whoever is closest to the load — which is usually the person with the least context.

Agree in advance who proposes mappings, who approves them, and where they are recorded. The record matters as much as the decision, because it is what makes a later difference explainable.

Find data-quality issues before they reach the destination

Profiling the source data early — counts, completeness, distinct values, outliers, records with missing mandatory attributes — surfaces problems while there is still time to fix them at the source. Fixing them at the source is almost always preferable to fixing them in transit, because a correction in the source is visible to everyone and survives a repeated load.

Reconciliation, opening balances and reporting baselines

Before any balance is migrated, the source position needs to be one people trust: bank accounts reconciled to a stated date, control accounts agreeing to their sub-ledgers, suspense and clearing accounts cleared or explained, and stocktake timing agreed where inventory is in scope.

Alongside that, capture a reporting baseline — the key reports as at the cut-off date, produced from the source system and retained. This is the reference against which the destination is checked, and it is far easier to capture before cutover than to recreate afterwards.

Manage the dependencies between parties

An ERP data workstream typically involves the source accounting system, the implementation partner, the business's finance team and often an external accounting practice. Delays are rarely caused by one party's failure; they are caused by a handover with no agreed date, or a decision waiting on someone who does not know they are the decision-maker.

• Source system access, extract format and refresh cadence — who provides each, and when
• Cleanup work — performed by the business, the practice or the partner, with a completion date
• Mapping approval — a named approver with the authority to sign off reporting structure
• Test load review — who checks the result, against what, and within what timeframe
• Cutover authority — who confirms the business is ready to commit

Prepare for a controlled cutover

A controlled cutover is a defined sequence with a freeze point, a final extract, a load, a validation pass, a review and an authorisation. Each step has an owner and an expected duration. The point of writing it down is not ceremony — it is that everyone can see what is left, and that the decision to proceed is made deliberately rather than by default because the weekend is ending.

Ledrix is designed around a structured approach to readiness, workflow visibility, validation and controlled cutover. For how that applies to implementation work, see for ERP partners, and for current product direction and availability see platform direction.