Dynamics · SAP · JD Edwards · Epicor · and the rest

SQL Server support for ERP systems

When the ERP is slow, the business stops — and the application vendor will tell you the application is behaving correctly. Specialist SQL Server support for the database underneath your ERP, from $1,500 a month.

Free 20-point health check Call 1800 431 416

An ERP support contract rarely covers the database. It covers the application: its code, its certified configuration, its patches. When finance reports that month-end is taking three hours longer than last quarter, the vendor checks the application, finds it behaving exactly as designed, and closes the ticket — correctly.

The problem is usually a layer down. Statistics that have gone stale on a table that has doubled in size, an index that was right three years ago, a query plan that changed after a patch, tempdb contention that only shows up under month-end concurrency, or a maintenance job that silently stopped running in March. None of that is the vendor's to fix, and none of it is visible from inside the application.

What this usually looks like

The calls we get about ERP databases

Different ERP products, remarkably similar failure modes — because they are database failure modes, not application ones.

Month-end got slower, gradually

Nobody can point to the day it changed, which is the signature of growth meeting a configuration that was tuned for a smaller database. Usually statistics, indexing and tempdb rather than hardware.

The vendor says the application is fine

And they are usually right. The question nobody is positioned to answer is what the database is doing while the application waits — which needs someone looking at wait statistics and query plans, not application logs.

An upgrade is blocked on a version

The ERP vendor certifies a SQL Server version you are not on, or will not certify the one you have moved to. Resolving that is a database project with an application deadline attached.

Reporting is competing with the ledger

Reports and extracts running against the production instance, at the same time as the people trying to close the month. Separating them is often the single largest improvement available.

The database has never been restored

Backups have run every night for years and nobody has ever mounted one. An ERP restore is also a test of whether the integrations, interfaces and reporting layer come back with it.

Nobody owns the database

The ERP is owned by finance, the server by infrastructure, the application by a vendor — and the database by nobody in particular. That gap is where most of these problems live.

Working alongside your ERP vendor

How we stay on the right side of your support agreement

The fastest way to create a problem is to tune a database in a way that voids the application vendor’s support. So the constraint comes first.

We establish what the ERP vendor certifies and supports before changing anything — version, patch level, configuration settings and, critically, whether index changes are permitted
Where the vendor prohibits schema or index changes, we work within that and say plainly what it costs you in performance
Changes are evidenced: a measured baseline before, the change, and the same measurement after, so the vendor can see what was done and why
We will talk directly to your ERP vendor where it helps, with your approval — a database engineer and an application engineer on the same call resolves things that email cannot
Upgrades are tested against a restored copy, including the integrations and the reporting layer, not just the database
Nothing is changed in production without an agreed window and a tested rollback

Getting started

From "month-end is slow" to a measured answer

The point of the first phase is to replace an opinion with a measurement, because that is what any argument with a vendor needs.

Measure before touching anything

Wait statistics, the expensive query plans, index and statistics health, tempdb configuration and the maintenance jobs that are meant to be running. The free 20-point health check covers this on one instance.

Separate database from application

Establish which of them is actually waiting. This is the finding that ends the loop with the vendor, in either direction — including when the honest answer is that the application is the problem.

Fix inside the certified envelope

Statistics, indexing where permitted, tempdb, memory and maxdop, maintenance jobs, and moving reporting off the production instance. Measured against the same baseline afterwards.

Then keep it that way

ERP databases regress as they grow. Ongoing monitoring catches the drift, and the monthly service hours exist to act on it before finance notices it again.

Is it the database or the application?

The free 20-point health check answers that for one instance, using read-only scripts you can read before they run. You get the written findings whether or not you engage us — including when the answer is that the database is fine.

Book the free health check

Published 9 October 2026

FAQ

Common questions

Because the two cover different things. The vendor supports the application and its certified configuration. A DBA covers the database underneath it: query and index performance, statistics, tempdb, backup and restore, high availability, patching and the 2am outage. The clearest test is to ask your vendor what they will do when the application is behaving correctly and month-end is still slow.

No. We establish what the vendor certifies and permits before anything changes, and where they prohibit index or schema changes we work within that constraint and tell you plainly what it costs in performance. Every change is evidenced with a before-and-after measurement, which is also what the vendor needs if they are asked to look at it.

Any ERP whose database runs on SQL Server, Oracle, PostgreSQL or MySQL — in practice that covers Microsoft Dynamics 365 Business Central, NAV, AX and GP, SAP on SQL Server, Oracle JD Edwards and E-Business Suite, and mid-market products such as Epicor, Sage, Pronto and MYOB, plus heavily customised in-house systems. We are specialists in the database, not in the application, and we are explicit about that line.

Yes, on the database side: version and compatibility assessment, the migration itself, testing against a restored copy including integrations and reporting, and a tested rollback. These run as fixed-price projects scoped after the assessment. The application side stays with your ERP partner, and we coordinate with them.

The free health check is a set of read-only scripts you can run the same day, with a written report within 3 business days of the output reaching us. If it is urgent and you have no agreement with us, emergency support is available at $180 per hour. On a monthly plan the response SLA is one to two hours depending on tier, at any hour.