An ERP migration in a 20-person company is a project that looks smaller than it is. A three-month plan typically wraps up in six, an 80,000-zloty budget closes at 140, and after go-live the warehouse stock is off by double-digit percentages. Not because the software is bad. Because nobody verified the assumptions the whole project was standing on.
Last year we talked to a 12-person furniture manufacturer who had just finished moving from Subiekt GT to Comarch Optima. Four months of migration work, and two weeks after go-live they discovered historical stock levels were off by 18%. The cause: in the old system, some raw materials were tracked in linear meters and some in square meters, and during data mapping into the new ERP everything was carried over as plain "m". Nobody had verified it, because "the data will be migrated automatically". For two weeks the company was selling things it didn't physically have, and refusing orders for things sitting in the warehouse. Cleaning it up took six weeks and cost more than the migration itself.
This isn't an exotic case. This is a typical ERP migration in a Polish SME, unless someone enforces hard discipline before kickoff.
Where the problems come from
Most migration problems share one root cause: the data in the old system doesn't mean what you think it means. The "product description" field in an eight-year-old Subiekt install holds a mix of trade names, manufacturer codes, internal warehouse notes and the occasional project number. The "customer notes" field holds all the tribal knowledge about how they actually pay at 90 days despite the 30-day contract. None of this is written down anywhere — it lives in the heads of three people who are currently on holiday.
The second classic problem: customisations nobody remembers why they were needed. Every long-running ERP carries three to seven "weird" things: hand-built reports, modified print templates, Excel macros that translate ERP output into something the accountant understands. The new vendor usually doesn't see any of this until someone in the company says "oh, by the way, we also need that report to show…".
The third: a process that the company runs differently from how the off-the-shelf ERP runs it. This isn't a technical problem, it's an organisational one. You either adapt the process to the system (and someone has to accept that the old way is gone), or you adapt the system to the process (and you pay for that not just now, but at every upgrade for the next five years).
A plan that actually works
A realistic ERP migration plan in an SME looks different from the one on the vendor's slides. The things that genuinely have to be in there:
- Data inventory before migration — not "we'll export from Subiekt", but: which table, how many rows, which fields, what values are actually in there. That's typically two to three weeks of work. Without it, everything that follows is guessing.
- Catalogue of customisations and workarounds — built with the people who actually use the system, not with the department head. Asking the warehouse worker "show me what you do differently from the manual" gives you more information than two days of workshops.
- Data mapping verified on a sample — migrate 200 representative records first, check by hand. Then 20,000.
- Parallel running, not big bang — for at least two weeks after go-live the old system has to keep running in parallel, even if read-only. Otherwise you have no way to verify whether something drifted.
- A disaster-recovery test — before production go-live, run the test: server is down, how long does it take to restore full operations. If the answer is "we don't know", you're not going live yet.
This plan adds 30–40% to the timeline the vendor proposed. But it cuts 60–80% off the "fixing things after go-live" time, which is almost always underestimated.
Red flags when picking a vendor
A few things that should raise warning lights when you're talking to an implementation firm:
- A quote without a data audit. If someone gives you a fixed price after a single meeting and without looking inside your current database, that's not a quote. That's an opening offer that will grow during the project.
- "Data migration" as one line item. It should be broken down into: extraction, cleansing, mapping, test load, verification, production load. Each of those words is a different scope of work and a different cost.
- No references at your scale. A vendor doing rollouts for 200-person companies doesn't necessarily know how to do one for a 25-person company. Different team, different budget, different decision speed. Ask for a customer of a similar size, ideally in your industry.
- The promise that "everything will be just like now, only better". It won't. Some things will be better, some will be worse, some will simply be different. A vendor who doesn't say this out loud is selling you peace of mind that doesn't exist.
- No "project owner" role from your side. If the vendor doesn't insist that you assign a single person with decision authority for at least 30% of their time over half a year, they don't know what they're doing. Or they do, and they're profiting from the fact that you don't.
What to test before go-live
Before you flip production over, walk through five scenarios on the new system using real (or very close to real) data:
- Full sales cycle — from order, through invoice, to bookkeeping. With three typical customers and one atypical one (e.g. foreign customer, reverse-charge VAT).
- Full purchase cycle — goods receipt, supplier invoice, posting to ledger. With particular attention to services that don't carry stock.
- Month-end close — in test mode. If the accountant says "I don't know how to do this" after the exercise, you're not going live yet.
- Partial inventory count — pick one product group, count physically, compare with the system. A delta above 2% means data isn't where it needs to be.
- Server failure — power down, restore from backup, check how long and how complete. It's boring, and it's exactly what nobody does and exactly what people regret most afterwards.
What next
An ERP migration isn't an IT project. It's an organisational project with an IT component. Most companies that fall into the "second migration in three years" trap made the same first mistake: they handed the whole thing to the software vendor and came back when "it was ready". There's no such moment. A migration is ready when your people can work in the new system without prompts — and for that to happen, you have to stay inside the process.
If you're planning an ERP change in the coming months or you're stuck mid-implementation right now — let's talk. The first call is free and takes half an hour. Often it's enough to point at where the biggest risk is and what can still be saved without resetting the whole project.
An ERP migration is ready when your people can work in the new system without prompts — not when the vendor says they're done.