Migrating to an ERP in an SME: steps, data migration and accounting pitfalls (2026)

Changing ERP is one of the most significant projects an SME can undertake. It touches sales, purchasing, accounting, inventory and sometimes payroll simultaneously. Well prepared, it delivers lasting productivity gains. Badly managed, it produces corrupted data, impossible year-ends and operational disruption that can last months.

This guide focuses on what ERP integrators often treat superficially: the handover of accounting and tax data. That is where the reliability of the new system is determined — and where the accountant must be involved from the outset.

In short: a successful ERP migration follows eight steps (scoping, selection, configuration, data migration, acceptance testing, training, go-live, post-launch support). Data migration is the riskiest phase. It covers the opening general ledger (brought-forward balances), the detailed ledger, outstanding customer and supplier balances, fixed assets with their depreciation schedules, and inventory. The FEC audit file (Fichier des Écritures Comptables) must be valid before and after the cutover. And from 2026 onwards, the ERP must be ready for mandatory e-invoicing in France.

The project follows a logical sequence. Each step produces a deliverable that conditions the next.

Project governance matters: a single project owner on the SME side, regular progress checkpoints, and formal go/no-go decisions at each critical milestone.

How long does an ERP migration take in an SME?#

Duration varies widely by scope. For an SME of 10 to 50 employees covering accounting, purchasing, sales and inventory, expect somewhere in the range of 3 to 9 months from scoping to a stable go-live. Data migration and acceptance testing are the two phases that absorb the most slippage when underestimated at the outset. A realistic plan builds in explicit buffers for data cleaning iterations and user testing rounds.

Accounting data migration is at the heart of the risk. Unlike commercial data (customer records, product catalogues), accounting data demands absolute precision: a single euro of difference between the old and new ERP produces an anomaly that can propagate through every subsequent closing.

What needs to be migrated#

Five distinct scopes must be covered:

• Opening general ledger (brought-forward balances): the balance on each account at the first day of the first financial period in the new ERP. Any error here distorts every future financial statement.
• The detailed ledger: transaction-level entries for the current year, if the cutover happens mid-year. Often the largest volume and the longest to verify.
• Outstanding customer and supplier balances: every unpaid invoice must be carried across with its reference number, date, amount, VAT breakdown and due date. These are the basis for collection and doubtful-debt provisions.
• Fixed assets and depreciation schedules: each asset needs its historical cost, commissioning date, depreciation method and rate, and net book value at the cutover date. An incorrect depreciation table compounds over multiple years.
• Inventory: quantities and unit values per reference, using the method applied (weighted average cost or FIFO — LIFO is not permitted under French accounting rules).

The migration sequence#

The migration runs in four stages: extract from the legacy system, clean (duplicates, missing fields, incompatible formats), map to the new ERP's chart of accounts, load, then verify. Verification is the phase projects most consistently underestimate. It must compare balances account by account between the old and new systems.

Worked example. On a B2B distribution client we support, the opening balance contained 412 active accounts. The initial load migrated 398 correctly. The 14 accounts with discrepancies represented a €23,400 difference on supplier payables, including €8,900 of recoverable VAT carried forward. Without a line-by-line check, those gaps would have gone undetected until the first VAT return after go-live.

The FEC (Fichier des Écritures Comptables) is the standardised file that the French tax authority (DGFiP) requires in the event of a tax inspection (Article L47 A-I of the Tax Procedures Code). Its format is defined by the ministerial order of 29 July 2013.

An ERP migration creates two specific FEC risks:

1. The FEC for the year in which the cutover occurs may become composite: part of the entries sit in the legacy system, part in the new one. The tax authority expects a coherent, continuous FEC. You must anticipate the production of a consolidated FEC for the transition year.
2. The accounting configuration of the new ERP may generate non-compliant entries: miscoded accounts, journals without analytical codes, truncated descriptions. These anomalies are invisible in day-to-day management reports but cause FEC validation to fail.

We recommend producing and validating a test FEC on the first batches of entries in the new ERP before the final go-live. Catching structural anomalies early is far less costly than correcting a full year's worth of non-compliant entries after the fact.

The cutover date has direct accounting implications. The ideal is to cut over at a year-end or at the start of a new financial year: the opening balance is then the only data requiring detailed migration, and closed years remain entirely in the legacy system.

Cutting over mid-year is feasible but more complex: the detailed ledger must be migrated from the first day of the current year, invoice numbering sequences must be maintained continuously, and a transition FEC must be produced.

Planning a parallel-run period of at least two to four weeks after go-live is strongly advisable: teams work in the new ERP but cross-check summary reports against the legacy system. It costs time, but it is the most effective safety net.

Big bang or phased cutover?#

Two approaches exist:

• Big bang: everything switches on a single date. Faster, but any problem hits all areas simultaneously.
• Phased: by module (accounting first, then sales, then inventory) or by site. Safer, but requires careful documentation of the temporary dual-system period.

The choice depends on the company's size, number of sites, and the team's capacity to manage the complexity of a transitional parallel period.

From 1 September 2026, all French companies are required to receive e-invoices. Issuing e-invoices becomes mandatory for large companies and mid-caps from the same date, and for SMEs and micro-businesses from 1 September 2027, via an accredited dematerialisation platform (PDP).

This changes the ERP selection criteria. A system that cannot connect to an accredited PDP, or that does not handle Factur-X, UBL or CII formats, creates an immediate compliance gap. Before finalising the tool choice, verify that the ERP-to-e-invoicing connection is operational and tested — not just listed as a feature on a product sheet.

Verifying e-invoicing readiness now forms part of every ERP migration specification.

Migrating to a new system does not end your retention obligations. Accounting records and supporting documents must remain accessible and legible for:

• 6 years for tax purposes (Article L102 B of the Tax Procedures Code)
• 10 years for commercial purposes (Article L123-22 of the Commercial Code)

In practice, two options: maintain read access to the legacy system, or archive its data under conditions guaranteeing integrity and retrievability. Archiving is often the less costly option over time, provided a durable and documented format is chosen. A poorly documented migration can make closed financial years unreadable in the event of a tax inspection — a real risk, not a theoretical one.

An ERP migration is a personal data processing operation under the GDPR. It involves customer, supplier and employee data. The minimisation principle applies: you migrate only useful data, and you do not use the migration as an opportunity to retain information whose legal retention period has already passed.

In our experience, migration projects frequently reveal customer records that have been inactive for 8 to 10 years and were never purged. This is the right moment to clean up the data register, formalise retention periods in each module of the new ERP, and document the process.

A perfectly configured ERP that teams refuse to use is an operational failure. Change management is not a comfort feature — it determines the project's return on investment.

Practical levers:

• Involve a representative from each department during scoping, not just at training stage.
• Train on real use cases from users' actual daily workflows, not on generic demo data.
• Appoint internal champions per module, able to answer colleagues' questions without systematically escalating to the integrator.
• Listen to feedback in the first weeks: it reveals misconfigured settings or untested workflows that acceptance testing missed.

Buy-in is built before go-live. After the cutover, it is too late to persuade.

ERP vendors and integrators know their product well. They are less familiar with the accounting and tax specifics of your file: the depreciation method applied, whether VAT is declared on invoicing or on collection, a non-standard financial year, group tax consolidation, or a customised chart of accounts built up over several years of operations.

The accountant brings three concrete contributions to an ERP project:

1. Validating the target chart of accounts and its mapping from the existing one before data is loaded.
2. Checking the opening balance and depreciation schedules after migration, before go-live.
3. Validating the test FEC on the first entries in the new system before anomalies accumulate over a full year.

These three checkpoints are typically absent from the integrator's default project plan. Building them into the engagement from the start avoids costly corrections mid-year.

Updated 2026-06-14. This article is for information purposes and does not replace personalised advice. For your specific situation, consult a registered expert-comptable.