Most investigations start with a sentence rather than a measurement. "Month-end is slower than it used to be." "Reports time out after nine." "The system is slow." Each is a real report of a real experience, and none of them names a cause.
That gap — between the symptom somebody reports and the layer that actually owns it — is where most wasted effort in this work lives. What follows is seven things that decide whether an estate stays stable, written as the questions worth asking rather than as answers that would need to know your system.
The system behind the symptom
One user complaint can come from any of several places: the application and its extensions, the service tier, the query plans and indexes, the storage and network beneath those, or an integration that quietly turned a set-based write into a row-by-row one. All five produce the same sentence.
This is why adding compute so often changes nothing. If the constraint is storage latency while posting and reporting overlap, a bigger server is an expensive way to wait. The fix is not more of something — it is finding which layer is actually the constraint, which cannot be done from the complaint alone.
Four minutes to post
A number nobody wrote down is a number nobody can defend. Teams often know that something "used to be quicker" without knowing what it used to be, which turns every conversation about performance into a matter of opinion.
The cheapest useful thing most estates are missing is a recorded baseline for the handful of operations the business actually feels: the posting run, the month-end close, the report that somebody waits on. Not a dashboard of everything — three or four numbers, dated, so the next argument is about evidence.
The index trap
Indexes are added to solve a specific problem on a specific day, usually successfully. What is rarely revisited is what each one costs afterwards. Every index is written on every insert and update, forever, in exchange for reads that may have stopped happening years ago.
So the question is not "do we need more indexes" but "which of these are we still paying for and no longer using". On SQL Server the usage statistics can answer that directly; the reason it rarely gets asked is that nobody owns it, not that it is difficult.
- Indexes written constantly and read rarely are pure cost on every posting run.
- A table that is only ever appended to — change logs, job queue entries, integration records — is the most common cause of a system that was fine for years and then was not.
- Neither shows up as an incident. Both show up as a number that is slightly worse each quarter.
Migration is not modernization
These are different projects with different costs, and confusing them is expensive. A migration moves what you have; if the data model was wrong on-premises it is wrong in the cloud, now with a monthly bill. That is a legitimate choice — but it is a scheduling decision, not an improvement, and calling it one sets expectations nobody can meet.
Modernization means something actually changes: how the data is shaped, where the work happens, what becomes possible that was not. It costs more, takes longer, and is sometimes not worth doing. Both are defensible. What is not defensible is paying modernization prices for a migration and then wondering why nothing got better.
From alerts to outcomes
If a team has learned to ignore an alert, that alert is not monitoring. Alert fatigue is a design problem rather than a discipline problem: an alert earns its place only if it is actionable, owned, and rare enough that its arrival means something.
A useful exercise, on your own data: take a month of alerts and sort them into the ones where somebody did something and the ones where somebody acknowledged them. The second pile is the work. Either give each one a threshold that would move it to the first pile, or stop sending it.
Backup is good. Recovery is better.
A backup that has never been restored is a hypothesis. Nearly every estate has backups; far fewer have a restore that has been run, timed, and watched by somebody holding a clock. The difference only becomes visible on the worst day of the year.
- How long does a full restore actually take — measured, not estimated?
- Who has done it, and when did they last do it?
- What does the business lose per hour while it runs?
- Does the runbook assume a person who still works here?
If those have no answers, what exists is a backup job and a hope. The gap between the two is not technical; it is that nobody has been asked to schedule the rehearsal.
Stable today, ready tomorrow
Stability is not the absence of incidents. It is knowing where you would look. An estate where the cause is findable, the baseline is recorded, the indexes are accounted for, the modernization is honest about what it is, the alerts are acted on, and the restore has been rehearsed is not an estate that never breaks — it is one that recovers without drama.
None of that is glamorous and none of it appears in a quarterly deck. It shows up as the incident that did not happen, which is the hardest thing in this work to take credit for and the most valuable thing to have.
Veltheon is founder-led, based in Ontario, and works on Business Central and NAV, SQL Server, PostgreSQL and Azure. If something here sounded like your estate, the first conversation is free and costs nothing but half an hour — and we will say plainly when the honest answer is that you do not need us.