Every estate breaks sometimes. The difference between a stable one and a fragile one is not whether incidents happen, but what happens next. In a stable estate somebody knows where to look, the evidence is already being collected, and the way back is rehearsed. In a fragile one every incident starts from nothing.

Illustrative: a diagram of the idea, not a reading from a customer system.

The six habits, in one place

This is the last note in the series, and it is mostly a summary, because stability is the sum of the earlier six:

  • The cause is findable: telemetry is on, someone can query it, and investigations narrow by layer before they dig.
  • The baseline is recorded: the few operations the business feels have dated durations, so a regression is a number, not a mood.
  • The indexes are accounted for: each one is paid for by a read someone still needs.
  • The project is named honestly: migrations are budgeted as migrations, and modernization is a decision, not a label.
  • The alerts are acted on: few, owned, actionable, and reviewed.
  • The restore is rehearsed: timed, with names, into an environment where it is safe to practise.

Stability is what makes change safe

This is not only about avoiding trouble. A Business Central online estate changes whether you plan it or not: Microsoft ships two major updates a year, in April and October, and minor updates in the other months, with a preview period before each major update. An estate with a baseline can compare the week after an update with the week before. An estate with rehearsed recovery can try a change knowing it has a way back. The same habits that keep it stable today are what let it take the next step, whether that is a new module, an integration or AI on top of the data, without betting the business on it.

The update cycle gives you a rehearsal slot for free. Before each major update there is a preview period, and Microsoft documents preparing for it with preview environments. An estate with a baseline can run its three or four business operations against the preview and compare them with last month's numbers, so the update is a known quantity before it reaches production rather than a surprise after it.

Azure's Well-Architected guidance makes the same point about reliability in general: test that a workload can withstand faults and recover, rather than assume it. Readiness is something you demonstrate, not something you declare.

A readiness review you can run

In our practice the quickest honest picture of an estate comes from asking six questions and accepting only evidence as an answer: Where would we look first if posting slowed down tomorrow? What did posting take last month? Which indexes have we not reviewed in a year? Which customizations would we retire if we upgraded now? Which alerts did nobody act on last month? When did we last restore, and how long did it take? Each "we don't know" is a short, specific piece of work, and none of them needs a new platform.

Where to start if the answers are thin

If most of the six questions come back as "we don't know", do not try to fix them all at once. In our practice the order that pays back fastest is: recovery first, because it is the only one whose failure can be unrecoverable; then telemetry, because every other habit depends on being able to see; then the baseline, so the next change can be judged; then alerts, indexes and customizations as the evidence points at them.

Each step is small on its own. Together they turn an estate that is stable by luck into one that is stable by design, which is the only kind that stays stable through the next update, the next integration and the next person joining the team.

Five checks for this week

  • Ask the six questions above of your own estate and write down the answers you can prove.
  • Put the next major update's preview period in the calendar, with a plan to test the operations in your baseline against it.
  • Choose the one "we don't know" that would hurt most on a bad day and give it an owner and a date.
  • Share the answers with the business owner of the system, not just IT.
  • Repeat the review after the next major update, and compare.

Veltheon is founder-led, based in Ontario, and works on Business Central and NAV, SQL Server and Azure. If one of these sounded like your estate, the first conversation is free and starts with the evidence you already have.

Sources and credits

  1. Update cycles — Microsoft Learn: major updates in April and October, minor updates in other months, preview periods
  2. Reliability in the Azure Well-Architected Framework — Microsoft Learn: reliability principles
  3. Reliability testing strategy — Microsoft Learn: testing that a workload withstands faults and recovers
  4. Monitoring and analyzing telemetry — Microsoft Learn: Business Central telemetry
  5. Creative Commons Attribution 4.0 (CC BY 4.0) — the documentation licence

Original Veltheon explanation. The films are illustrative artwork, not Microsoft or customer footage, and nothing here is a measured result from a customer system. Verify current documentation and your actual environment before changing anything.

Documentation references: Microsoft and contributors, Microsoft Learn (Business Central, SQL Server and Azure documentation), licensed CC BY 4.0. Concepts summarized by Veltheon; source wording and layout not reproduced.

Veltheon Field Notes is an independent publication, neither affiliated with nor authorized, sponsored or approved by Microsoft Corporation. Microsoft, Dynamics 365, Business Central, Dynamics NAV, SQL Server and Azure are trademarks of the Microsoft group of companies.

These are the personal views of Neeraj Kumar, based on about two decades of enterprise experience. General information, not advice for your environment.