"The ERP has slowed down, we probably need to replace it" — one of the most expensive sentences you can say at a board meeting in an SME. In 8 out of 10 cases we've seen in recent years, the real cause was findable in an afternoon and fixable in a week. No replacement, no migration, no two-year project.
That's not to say ERP systems never really age out. It means that before you go down a road that costs 300–800 thousand PLN, it's worth ruling out the things that cost a tenth of that and can be done over a weekend. This piece is about what that diagnosis looks like in the reality of Comarch Optima, enova365, Subiekt and similar systems that in Polish SMEs typically run on Microsoft SQL Server.
Facts first, not impressions
The first thing that surprises owners is how subjective the judgment "the ERP is slow" is. One person says "everything freezes on Friday afternoon". Another: "it's been worse for two months". A third: "issuing an invoice takes forever". Three different problems, three different causes, one shared sentence in an email to the board.
Before anyone starts poking at the database, gather specifics:
- Which operations are slow — opening a customer record, generating an invoice, running the monthly sales report, closing the period? These are completely different things technically.
- When it slows down — all day, only in the morning at startup, only during a big month-end report, only for certain users?
- How long has it been like this — since a specific update, since the team grew by 3 people, since the database crossed 10 GB, since the new internet provider showed up?
- How long exactly — with a stopwatch. "Slow" is not a number. "18 seconds" is a number.
This sounds like bureaucracy, but without those four answers any further diagnostics is guesswork, and any software vendor will happily sell you something you may not need.
A real example from the field
Something concrete, to keep this from floating. At one of our clients — a 12-person accounting bureau on Comarch Optima for 5 years — opening the VAT record after New Year's took around 40 seconds. On top of that, periodic freezes of a dozen seconds in the middle of the day, exactly when two people were saving invoices at the same time.
The diagnosis took half a day and looked like this: the SQL Server database had been growing uninterrupted for 5 years, the VatZakup and VatSprzedaz tables held over 8 million rows combined, indexes were 92% fragmented, and Auto Update Statistics had been switched off at some point "because it slowed things down at month-end". On top of that the server had 16 GB of RAM on a machine that also served the ERP, the pagefile lived on the same HDD as the database, and there were ten scheduled jobs running, four of which did the same thing.
The fix: rebuild the indexes in a maintenance window (2 hours), turn Auto Update Statistics back on with a sensible schedule, move the pagefile to a separate drive, dedupe the scheduled jobs. External cost: one day of work. Result: opening the VAT record dropped from 40 seconds to 3, the freezes disappeared. Replacing the ERP, which had come up at the last three board meetings, went back on the shelf indefinitely.
This isn't an extreme case. This is the typical case.
Four layers we look through
Once you know what specifically is slow, we go through four layers — from the cheapest diagnosis to the most expensive. In that order, because statistically that's how the probability breaks down.
Layer 1 — the database. This is where 60–70% of the problems we see actually live. Fragmented indexes, stale statistics, missing indexes on columns used in reports, "junk" tables from disabled modules, a transaction log that has ballooned to 40 GB. All diagnosable in a few queries against sys.dm_db_index_physical_stats and sys.dm_exec_query_stats. All fixable without touching the ERP itself.
Layer 2 — server and infrastructure. RAM allocated to SQL Server (the default 2 GB for Express is the classic trap), disk type (HDD vs SSD is a 20–50× difference), pagefile placement, an antivirus scanning MDF/LDF files on the fly, backups running hourly in the middle of the working day. Diagnostics: Task Manager, Performance Monitor, checking the SQL Server config. Fixes: often just bumping RAM from 16 to 32 GB sorts it out, adding exclusions to the antivirus is 15 minutes.
Layer 3 — network and clients. If the ERP is hosted on an office server and users connect over Wi-Fi from a 6-year-old access point, the problem isn't the ERP. Try RDP instead of the full client, review the VPN configuration, check whether there's one overloaded switch between the server and the desks. A separate strand: users working remotely over a weak link with batch files — one 5,000-item import can hang the server if the client's network is the bottleneck.
Layer 4 — the ERP itself and its configuration. Only now, once the first three layers are ruled out, do we look at the ERP config: enabled modules nobody uses (but which get pulled into every query), custom modifications in Optima (SDK, add-ons), badly designed printouts that trigger hundreds of thousands of queries, a report cache eating 20 GB. Fixes here are more expensive and often need the vendor, but at least you know you're discussing the real cause.
When replacement actually makes sense
Replacing the ERP is justified when the four-layer diagnosis shows one of three things: the vendor has stopped supporting the version you're on and you can no longer update; the system doesn't handle a process that is critical to the business today (e.g. you've added online sales and the ERP has no reasonable e-commerce integration); or the scale of data and users has simply outgrown the system's architecture — typical for firms that have grown from 15 people to 60 and are still on the "small office" edition.
All three reasons are real. They are also relatively rare. Much more often, behind "the ERP has slowed down" hides one of the causes above. Worth checking before the board signs a two-year migration contract.
What to do this week
You don't need to book an audit right away. Four things you can do yourself or with your in-house IT person within a week:
- Collect concrete measurements from the team — which operations, when, how long. Don't move on without this.
- Check the database size, SQL Server edition and how much RAM it has allocated. If it's SQL Server Express with 2 GB of RAM on a 30 GB database — that's layer 2.
- Look at the SQL Server scheduled jobs. If nobody has done a rebuild indexes and update statistics in 5 years — that's layer 1.
- Ask the ERP vendor point-blank: "what's the currently recommended database and server configuration for a company our size?". A short email is often enough to get back a "have you checked whether…" list.
If after those four steps you still don't know where the problem is — that's exactly the moment to call someone in from outside, but with specifics in hand, not with "we probably need to replace the system".
Before you spend 300 thousand on a new ERP, worth checking whether the old one just needs a day's work with SQL Server.