How ERP Data Conversion Actually Happens

The question is why ERP data conversion so often becomes the point of stress in an implementation. It is not because teams do not know where the data lives. It is because conversion sits at the intersection of business policy, accounting judgment, system design, and calendar pressure.

What’s at stake is not simply whether records load successfully. The real risk is whether the new ERP starts life with numbers the business trusts, structures the business can operate, and enough traceability to explain how opening balances were created. From first principles, data conversion is not an IT upload. It is the act of turning historical business activity into a controlled starting point for future operations.

The work gets done through a sequence of decisions, extractions, validations, rehearsals, corrections, and cutover controls. The mechanics matter. So does the order. A clean conversion is usually less about heroic effort at the end and more about disciplined narrowing of uncertainty over time.

Start With the Conversion Scope

Before anyone builds a template or extracts a file, the team needs to decide what will be converted and why. This is a business decision, not just a technical one.

Most ERP conversions include some combination of:

Master data: customers, vendors, items, employees, chart of accounts, locations, departments, projects.
Open transactions: open invoices, open purchase orders, open sales orders, unapplied cash, unfulfilled commitments.
Opening balances: general ledger balances, subledger balances, inventory quantities and values.
Fixed assets: asset master records, cost, accumulated depreciation, useful lives, books, and remaining depreciation.
Historical detail: selected prior periods, often limited and loaded for reporting rather than transaction processing.

The constraint is that not every piece of history should move. Legacy systems often contain years of inconsistent coding, inactive records, duplicate vendors, closed projects, and one-off workarounds. Converting all of it creates noise in the new system.

A useful rule is to separate operational necessity from historical reference. If the business must transact against it after go-live, it belongs in the ERP. If the business only needs to look it up, it may belong in a reporting archive.

Build the Data Map Before the Data File

A conversion file is the visible artifact. The data map is the control mechanism behind it.

The map defines how each legacy field becomes a target ERP field. It also defines transformations: old department codes to new departments, legacy account numbers to the new chart of accounts, vendor names to standardized legal entities, item categories to new product hierarchies.

This is where many problems surface. The legacy system may allow blank fields that the new ERP requires. One old code may split into several new values. Several old vendors may become one supplier record. A fixed asset may have been tracked in spreadsheets rather than in the legacy ERP.

The conversion team should document:

Source system and table or report.
Legacy field name and definition.
Target ERP object and field.
Required format and validation rule.
Transformation logic.
Owner responsible for sign-off.
Exception handling approach.

Without this map, every test load becomes a debate. With it, errors become traceable. The team can ask whether the issue is extraction, mapping, cleansing, configuration, or timing.

Fixed Assets Are Their Own Conversion Stream

Fixed assets deserve separate treatment because they combine operational records with accounting outcomes. The ERP needs to know what each asset is, where it belongs, how much it cost, how much depreciation has already been taken, and how it should depreciate going forward.

A typical fixed asset conversion includes:

Asset ID or new asset number.
Description.
Asset class.
Cost center, location, department, or project.
In-service date.
Acquisition cost.
Accumulated depreciation through the cutover date.
Net book value.
Useful life and remaining life.
Depreciation method.
Tax book or statutory book values, if applicable.
Parent-child relationships for component assets.

The first decision is whether to convert assets at a detailed asset level or summarized level. Detailed conversion supports future disposals, transfers, audits, and depreciation tracking. Summary conversion may be acceptable for fully depreciated or immaterial asset groups, but it reduces traceability.

The second decision is the conversion date. Fixed assets usually need a hard cutoff: depreciation is run in the legacy system through a specific period, then the new ERP begins depreciation in the next period. If the cutoff is unclear, both systems may calculate depreciation for the same period, or neither may do so.

The Fixed Asset Reconciliation

A good fixed asset conversion ties three views together:

The legacy fixed asset register. 2. The general ledger fixed asset and accumulated depreciation balances. 3. The ERP asset load file.

The total acquisition cost and accumulated depreciation by asset class should reconcile to the general ledger. Differences should be explained before go-live, not carried forward as vague conversion adjustments.

Common issues include assets recorded in the GL but missing from the register, disposed assets still appearing as active, assets assigned to inactive departments, and tax depreciation books that do not align with the corporate book. These are not upload problems. They are accounting cleanup decisions.

Rehearse in the Sandbox

The sandbox is where the conversion process becomes real. A first sandbox load is rarely clean. That is the point.

The team extracts data, applies mapping rules, loads it into the ERP, reviews errors, corrects source or template issues, and repeats. Each cycle should reduce the number and severity of exceptions.

A useful pattern is:

Cycle 1: Structural test. Confirm templates, required fields, formats, and basic object creation.
Cycle 2: Business validation. Confirm mapped values, balances, open items, asset calculations, and reporting outputs.
Cycle 3: Cutover rehearsal. Confirm timing, dependencies, approvals, file ownership, and production runbooks.

The sandbox should not be treated as a disposable playground. It is the rehearsal environment for production. If a load sequence fails in sandbox, it will likely fail under more pressure during cutover.

Sequence Matters More Than It Seems

ERP data objects depend on one another. The order of conversion is therefore part of the design.

A simplified sequence might look like this:

Configure core structures: legal entities, chart of accounts, calendars, currencies, departments, locations. 2. Load master data: customers, vendors, items, employees, projects, asset classes. 3. Load opening balances or prior period trial balances. 4. Load subledger detail: open AR, open AP, open purchase orders, open sales orders. 5. Load inventory quantities and values. 6. Load fixed asset records and accumulated depreciation. 7. Reconcile subledgers to the general ledger. 8. Validate reports, workflows, and downstream integrations.

The exact order varies by ERP, but the principle is constant: dependent records cannot load before the records they depend on exist. An open vendor invoice cannot load if the vendor master is missing. An asset cannot load if the asset class or depreciation book is not configured. Inventory cannot reconcile if item masters and locations are incomplete.

This is why late master data changes are expensive. A change to the chart of accounts, department structure, vendor naming standard, or asset class design can force rework across many conversion files.

Production Cutover Is a Controlled Compression

Production migration is not just the final sandbox load repeated one more time. It is a compressed event with less tolerance for ambiguity.

By cutover, the team should know:

Which files will be extracted, by whom, and when.
Which business processes must stop in the legacy system.
Which transactions are allowed during the freeze, if any.
Which reconciliations must be completed before load.
Which approvals are required to proceed.
Which loads are sequential and which can run in parallel.
Which reports prove the load was successful.
Who can approve exceptions.

Timing becomes the central constraint. The business may need to close a month, run payroll, ship product, pay vendors, and invoice customers. Conversion must fit into that operating reality.

For example, accounts payable may stop entering invoices in the legacy system on Thursday afternoon. The team extracts open AP Friday morning. The file is cleansed and loaded Friday night. Finance reconciles open AP to the GL Saturday morning. If the reconciliation fails, the team needs a decision path: reload, adjust, defer, or document.

The same applies to fixed assets. Depreciation may be run in the legacy system for the final pre-go-live month. The asset register is frozen. The conversion file is created with accumulated depreciation through that period. The new ERP starts depreciation in the next open period. This sequence must be explicit.

Data Readiness Is a Business Constraint

Data readiness is often described as a project task. In practice, it is a business constraint.

A vendor file cannot be ready until duplicate vendors are resolved and tax details are confirmed. A customer file cannot be ready until credit status, billing addresses, and parent-child relationships are agreed. A fixed asset file cannot be ready until finance decides how to treat fully depreciated assets, missing in-service dates, and assets under construction.

The conversion team can identify defects, but business owners must resolve many of them. This requires time on calendars, clear decision rights, and visible exception lists.

The best exception lists are simple. They show the record, the issue, the owner, the required decision, the due date, and the status. Long technical error logs are not enough. Executives and process owners need to see what is blocking readiness in business terms.

Reconciliation Is the Proof

A successful load message does not prove a successful conversion. Reconciliation does.

The team should reconcile at several levels:

Record counts: did the expected number of customers, vendors, assets, and open invoices load?
Control totals: do invoice totals, inventory values, asset costs, and accumulated depreciation match expected amounts?
Trial balance: does the opening GL tie to the approved source balance?
Subledger-to-GL: do AR, AP, inventory, and fixed assets tie to the general ledger?
Sample records: do selected records look right from end to end?

Reconciliation should be designed before cutover. If the reports needed to validate conversion are not available until after production load, the team is operating blind.

Keep the Archive Separate

One practical mistake is trying to make the new ERP serve as both the operating system and the historical archive. These are different purposes.

The ERP should contain the clean starting point needed to operate going forward. Historical detail can be preserved in a read-only database, reporting warehouse, document repository, or legacy archive. This reduces conversion volume while still supporting audit, tax, customer service, and management reporting needs.

The archive should be governed. Users need to know where to find prior invoices, asset history, old purchase orders, and supporting documents. Access and retention rules should be clear.