From Excel to an Israeli ERP: When to Move and How to Move the Data

Moving from Excel to an ERP is not a software project, it is a data project. The mistake that recurs on every such move is budgeting for the implementation and forgetting that what consumes the time is taking files built over years by different people and putting them into a system that has rules.

When a business actually needs to move

The signal is not row count. A spreadsheet with 40,000 rows can work fine. What indicates readiness:

• Two people need the same row at the same time. That is when "final copy", "final copy 2" and "final copy updated" appear.
• A number has to be defensible. When an auditor asks where a figure came from, and a spreadsheet cannot say who changed what and when.
• The same data lives in two places. One customer list at sales, another at collections, and they no longer match.
• The business needs tax documents. Invoices with sequential numbering are not something you manage in a sheet.
• Someone spends a day a month reconciling by hand. That is a number you can price against.

When not to move: if the process itself is undefined. An ERP enforces rules; a business that cannot describe its own process will find the new system blocking it in unexpected places. Describe the process first, choose a system second.

Why the data migration is the whole project

The common assumption is "there is a file, we import it". In practice, an Excel file built over years contains things an ordered system will reject.

1. There are no types

This is the root of most problems. In Excel everything is a cell, and the display misleads:

• Dates - some are real dates, some are text, and some flipped day and month without anyone noticing. 03/09 can be 3 September or 9 March.
• Phone numbers - Excel likes dropping the leading zero. 0521234567 becomes 521234567, and sometimes scientific notation.
• ID and company registration numbers - the same problem, plus lost leading digits.
• Amounts - a number with a space, a currency symbol, or a comma as a decimal separator is text. It looks like a number and does not behave like one.

The practical rule: export to CSV and open it in a text editor, not in Excel. Excel shows you what it thinks you meant; the text file shows what is actually there.

2. There is no uniqueness

A spreadsheet has no primary key. "Israel Company Ltd", "Israel Co" and "israel ltd" are three rows that are one customer. They must be merged before import, and that is human work no script does correctly on its own.

If the file has a company registration number, that is the key. If not, that is job one: add it. A week spent cleaning beats discovering a year later that one company has three customer cards and the revenue report is split between them.

3. There are rules only one person knows

Every business spreadsheet has a column whose meaning is written down nowhere. A background colour meaning "partly paid". A note in brackets after the name. A row someone adds by hand at the end of each month.

Those rules are business logic and they have to move into the system. If you do not explicitly ask "what does this colour mean", you find out in the first production month, when someone says the new system "does not show what was in the file".

4. There are historical errors

A duplicated row, an amount mistyped three years ago, a partly deleted customer. In Excel this is silent. In a system with validations it stops.

That is actually an opportunity - but you must decide in advance which wins: the old data or the new rule? That decision belongs to the business owner, not to whoever writes the import script.

What to migrate - and what not to

History belongs in an archive, not in the system. This is the most argued point, and the answer is nearly always the same: history loaded into the new system slows it, does not fit its structure, and produces reports that do not reconcile with the post-migration period. A frozen file in backup, openable when needed, meets the same need without the cost.

An order of work that holds

1. Describe the process before touching data.
2. Export everything to CSV and inspect it in a text editor.
3. Clean and deduplicate - duplicates, types, a unique key.
4. Import into a test environment of the new system. Not production.
5. Reconcile numerically - total customer balances in the file against the system. If there is a one-shekel gap, stop and understand why.
6. Parallel run - two to four weeks in both systems.
7. Cut over, keeping the old spreadsheet read-only.

The two steps people skip

Numeric reconciliation is what separates a migration that worked from one that appeared to. Do not count rows - sum amounts. An identical row count with a different total means something did not transfer correctly, and it surfaces a month later in a report.

The parallel run is not waste. It is the period in which the process nobody described gets discovered - and it always exists. Better discovered while a working fallback is still there.

What changes when the ERP is Israeli

• Tax documents. Once the system issues invoices, you are in territory where a mistake is not a row you delete. Document type and sequential numbering are decisions that require the accountant.
• Hebrew and RTL. Hebrew names usually pass through fine, but mixed Hebrew-and-number text is a source of faults that only surface in PDFs and exports.
• Allocation numbers. Confirm the flow handles the Tax Authority requirement - see invoice allocation numbers for developers.
• Integrations. If the store, CRM or payment gateway must talk to the system, see connecting an Israeli ERP to anything.

What fails, almost every time

• Importing into production "just to see". There is no clean way back.
• Importing without a unique key. The duplicates surface months later.
• Skipping the parallel run because the schedule is tight. That is precisely where the schedule actually breaks.
• Letting the developer decide what to do with incorrect historical data. That is a business decision.