Replacing a legacy Hungarian ERP without losing your data

When a swap is worth it, and when it is not

This section deliberately cuts both ways. Of the enquiries that reach us, roughly one in three gets the answer that replacement is unnecessary. Use the list below as a self-check before the scoping call.

Reasons to move, backed by the vendors’ own material

Every row below points at a fact taken from a vendor’s public page. None of it is an opinion about which system is good or bad.

Where the Hungarian field stands right now

The table carries only what the vendor publishes itself, plus, where marked, the indicative "from" price on the uzletiszoftver.com comparison site. That last one is not vendor data and usually refers to the smallest configuration. Queried on 14 August 2026.

NEXON is deliberately missing from this list. It is an HR, payroll and time platform, not an ERP. The company states that its payroll software runs payroll for one million employees, and in our experience that is a system to integrate rather than replace.

Migrating data out of a system with no API

This is the part most proposals cover in one line, even though most of the project risk lives here. We work on four levels and always start with the cheapest.

1. Level 1: the vendor's own export

   Almost every Hungarian business system produces a bookkeeping feed, a CSV or XML output, sometimes an old but working ODBC view. This is the cheapest channel, nobody objects to it, and it does not put your contract at risk. The weakness is scope: it is usually tuned to the finance core, so custom item attributes, delivery addresses attached to partners and order history rarely make it through.

2. Level 2: a read-only copy of the database

   This is where the real work starts. We restore the system's daily backup onto a separate server and read from there, so production takes zero load. Under Firebird from a gbak or nbackup file, under MS SQL from a restored copy or a readable replica, under PostgreSQL through logical replication. Mapping the schema is manual work: table names in abbreviated Hungarian, no documentation. On a mid-sized system it takes two to three weeks before you know which 40 of the 600 tables hold the business truth.

3. Level 3: data already filed with the tax authority

   This is the trick you rarely see. Your outgoing invoice data already sits in the NAV Online Számla system and can be queried back. That gives you an independent check against your own export. If the two sets do not line up, the problem is not the migration, it is the source data, and week three of the project is a much better time to learn that than the first month-end close.

4. Level 4: RPA, and only as a last resort

   If a field will not come out any other way, we drive the desktop client by machine: log in, open a list, filter, press export. It is slow, brittle, and any version upgrade can break it. We never make it the main channel, only a patch for one or two missing fields, usually as a single run. Building a whole migration on RPA puts the project risk in the worst possible place.

One thing we always check before starting: what your software contract says about direct database access. In some cases it needs permission. Then we ask the vendor for an export and work with a combination of level one and level three instead of level two. Slower, but clean.

What to measure before anyone goes live

A migration is finished when it can be proven with numbers. We run the checks below on every project, and the accountant signs the record.

• Record counts per table on both sides. When they differ, soft-deleted rows are the usual cause: older Hungarian systems tend to flip a status field rather than delete.
• Totals per VAT rate and per period. The grand total is not the interesting number, the breakdown is, because rounding logic differences surface exactly there.
• Character encoding. Mixed encodings are common in decade-old Hungarian databases, and they show up first in partner names, on the long ő and ű characters. Fix that in the migration script, not by hand afterwards.
• Business logic hidden in free-text fields. If colleagues have been typing codes into the notes column for ten years, that is real data. Extracting it into proper fields is part of the migration.
• Open items handled separately. Open receivables and payables, stock quantities and account balances move at the moment of cutover, not together with the historical data.

Parallel operation and cutover

The order matters more than the calendar. The breakdown below assumes a mid-sized project of five to seven modules; we fix the actual durations after the scoping call, because the state of the data layer cannot be estimated in advance.

1. Migration audit

   Schema mapping, backup restore, sample extraction, and identifying the data channels that are missing. At the end we know what comes out and what does not. If it turns out the swap is unnecessary, we say so.

2. Loading historical data

   Master data first, then transaction history. We write the loaders to be idempotent so they can be re-run any number of times, because in practice there will be five or six rounds.

3. Shadow run

   The new system receives the same daily transactions, but the old one stays the source of truth. Automated daily reconciliation, discrepancy report by morning.

4. One full month-end close in both systems

   This is the real exam. Trial balance, VAT return base data, inventory value. The tolerance is agreed up front, and there is no cutover until it is met.

5. Cutover and afterlife

   Open items move during a frozen weekend, then the new system goes live. The old one stays readable, and we keep the rollback option open until the first close.