Those may all become relevant. But at that point, one important question is often still unanswered: what exactly are we trying to protect the service against?

A failed Windows node is not the same problem as losing a storage system. An unavailable SQL Server instance is different from losing an entire site. Planned maintenance creates another requirement again. If we do not separate those situations first, choosing the technology becomes partly guesswork. We are already discussing the architecture before we have defined what it actually needs to do.

SQL Server high availability starts with the failure the service needs to survive

High availability is not a single condition. A production application can become unavailable because the server hosting SQL Server fails, because Windows or the SQL Server service has a problem, or because storage becomes inaccessible. The network path between the application and database can disappear as well. SQL Server itself may be completely healthy while clients can no longer reach it.

The scale of the required protection also varies. One environment may only need to tolerate the loss of a single physical or virtual server. Storage, networking and the data center may already provide sufficient redundancy. Another workload may need to continue operating after the loss of a complete storage platform or location. Both are legitimate requirements, but they lead to different architectures.

This is where technologies such as Failover Cluster Instances and Availability Groups enter the discussion, although they solve different parts of the problem. An FCI provides redundancy for a SQL Server instance across Windows Server Failover Cluster nodes, while the database files remain on storage accessible to those nodes. An Availability Group maintains database replicas on separate SQL Server instances and can move the primary role between them.

That difference matters, but it still does not tell us which design is appropriate. If the relevant failure is the loss of a Windows node while the shared infrastructure remains available, one architecture may be sufficient. If the requirement also includes a separate copy of the databases or protection against failure of the original storage platform, the design has to cover a wider failure domain.

The same reasoning applies beyond SQL Server. Two database servers do not automatically remove every single point of failure. Both systems may still depend on the same storage platform, network components, DNS infrastructure, authentication services or physical location. That does not make such an architecture wrong; shared components may themselves be highly available. What matters is knowing where the common dependencies are and whether they sit inside or outside the failure scenario the design needs to handle.

When reviewing an HA design, I therefore find a different question more useful than simply asking whether two SQL Servers exist: which failure could remove both systems, or make both unreachable, at the same time?

That usually gives the architecture discussion a much clearer boundary.

RPO and RTO need to be requirements, not consequences

Once we understand the failure scenarios, the next question is what the organization expects to happen after one of them occurs. How much committed data can the business afford to lose, and how long may the service remain unavailable?

We normally describe these requirements as recovery point objective and recovery time objective. They should influence the architecture before the team selects a technology. They should not become numbers derived afterwards from whatever solution the team happened to implement.

A workload that can tolerate several minutes of potential data loss gives the architecture more options. A transactional system where losing acknowledged transactions would create a serious business problem has very different requirements. The same applies to recovery time. If an application can remain unavailable for an hour, the design does not need to behave like a system expected to resume operation within a few minutes.

Availability Groups provide a good example because the configuration itself changes the recovery characteristics. Synchronous and asynchronous commit modes make different trade-offs around transaction protection, latency and distance. A synchronized synchronous replica can support failover scenarios without losing committed transactions under the conditions covered by that design. An asynchronous replica, by contrast, may not yet contain the latest transactions when the primary fails.

Microsoft also provides guidance for monitoring and estimating RPO and RTO for Availability Groups. That is useful because these values depend on the actual configuration and data movement rather than on the product name alone.

RTO depends on much more than the SQL Server role change. After a failover, the new primary must become usable, clients need to reach the correct endpoint and application connections have to recover. Listener configuration, DNS, network paths, authentication, connection strings and client retry behavior can all influence what users actually experience.

This is why I would not define recovery time as the number of seconds required for SQL Server to complete a failover. The relevant measurement is the time until the service the business depends on works again. We looked at the same distinction from another direction in SQL Server Restore Validation: a database being ONLINE is an important technical state, but it does not prove that users can actually use the application service again.

The same separation is useful for backups. High availability can reduce interruption caused by certain infrastructure failures, but it does not provide the recovery options of a properly designed backup strategy. An accidental DELETE, an unwanted application change or another logical problem can reach additional replicas as part of normal data movement. If the requirement is to return to an earlier state, that is a recovery problem, not simply an HA problem.

This distinction is also important when looking at SQL Server backup strategy. High availability and backup can both support service continuity, but they protect against different failure scenarios. Teams should not treat them as substitutes for each other.

Maintenance is part of availability too

Unplanned failures naturally dominate high availability discussions, yet many production systems experience planned maintenance far more often than catastrophic infrastructure failure. Windows needs patching, SQL Server needs updates, virtualization hosts need maintenance and hardware eventually gets replaced.

Those activities belong in the architecture discussion because the chosen design determines how the workload can move and how much disruption routine maintenance creates.

If a service may only be unavailable for a few minutes, the team needs a practical and repeatable way to move production away from the component that needs maintenance. That includes more than issuing a failover command. Someone needs to know whether the target system is ready and whether application connections move as expected. The team also needs to understand how jobs and supporting services behave and what happens if it cannot complete the planned work.

A different environment may have a generous maintenance window and no business reason to eliminate every planned interruption. In that situation, additional HA components can create complexity without solving a requirement that actually exists.

That trade-off is easy to miss when the discussion starts with technology. More redundancy can remove failure points, but it also introduces additional components, configuration and operating procedures. Availability Groups, Windows clustering, listeners, endpoints, multiple SQL Server instances and possibly multiple locations all become part of the operating model. The team needs to monitor and understand them. During normal operation that complexity may remain almost invisible, but during an incident or maintenance window it suddenly becomes part of the recovery process.

For that reason, I consider operational capability part of the architecture rather than something to document afterwards.

This becomes particularly important in environments that have been running for many years. People change roles, applications evolve, teams replace infrastructure and the original reasons behind technical decisions become less obvious. An Availability Group or cluster may still be healthy according to monitoring while nobody is entirely comfortable performing a controlled failover because the team no longer fully understands the dependencies around it.

The technology has not necessarily become unreliable. The operating model around it has changed.

That is also one of the things worth looking at during a SQL Server Health Check. The existence of an HA configuration tells us relatively little on its own. Its purpose, dependencies, maintenance procedures and current level of operational understanding are much more informative.

Testing a SQL Server high availability design

Documentation and architecture diagrams can describe what should happen during a failure. A controlled failover shows what actually happens.

It verifies whether the expected node or replica can take over, but that is only the beginning of the test. The application also needs to reconnect, monitoring should recognize the role change and required SQL Server Agent jobs and supporting processes need to behave correctly. The team also needs a reliable way to decide whether the service is healthy after the transition.

Testing turns an assumed recovery time into something measurable. It may show that SQL Server changes roles within seconds while the application needs several additional minutes before users can work again. It can expose a DNS dependency, a connection string that still points directly to one server or an operational step that everyone assumed automation would handle.

Those findings are not arguments against the HA technology. They are information about the complete service.

This is why I am cautious with designs that look convincing on paper but that teams rarely exercise. If the team considers failover too risky to test during a controlled maintenance window, relying on the same process during an uncontrolled production incident deserves closer examination.

AG or FCI becomes a useful question after this

Once the failure domain, recovery objectives, maintenance requirements and operating model are clear, comparing SQL Server technologies becomes much more productive.

An FCI can be a natural fit where instance-level continuity is important and the surrounding storage architecture already provides the required availability. An Availability Group can fit a design that needs separate database replicas, database-level failover or replicas across different infrastructure or locations. In some environments, teams deliberately combine the technologies because they address different failure scenarios.

There are further differences around storage, networking, instance-level objects, licensing, readable replicas, administration and SQL Server version capabilities. Those details matter when evaluating a concrete architecture, but they are not a substitute for the requirements that lead to it.

A long AG-versus-FCI feature matrix can otherwise create a false sense of precision. A feature may be technically attractive without solving a problem the workload actually has. Conversely, a comparatively simple design can be completely appropriate when it matches the required failure domain, RPO, RTO and operating capabilities.

Before approving a SQL Server high availability design, I would therefore want to describe several scenarios in ordinary language. We should know what happens when one Windows node disappears, when storage becomes unavailable and when the primary location can no longer be used. For each relevant scenario, we should also understand how much data the business could lose and how long the application may remain unavailable. Finally, the team should have demonstrated the recovery process rather than only documented it.

That gives us something much more useful than starting with the question, “Should we use an Availability Group or an FCI?”

It tells us what the architecture actually needs to accomplish.

Once that is clear, choosing the SQL Server technology becomes a technical decision with defined boundaries rather than the starting point of the design.

Foto von huanyu chen auf Unsplash

The post SQL Server High Availability: Define the Failure Before Choosing the Technology appeared first on CraftedSQL.

The problem starts when people treat the plan as if it were the complete explanation for a performance incident.

Suppose users report that an application was slow around 10:00. Someone investigates an hour later, runs the query again and captures an actual execution plan. The query is fast now. The plan looks reasonable. There may still be useful clues in it, but we are already looking at a different execution under different conditions. If I want to understand what happened at 10:00, the plan captured at 11:00 is only one part of the evidence.

That distinction sounds obvious, but it matters because execution plans are very persuasive. They are visual, detailed and concrete. It is easy to find an operator that looks suspicious and start tuning from there, even when we have not yet established whether that operator had anything to do with the problem users experienced.

What SQL Server execution plans can tell you

An execution plan describes the strategy SQL Server selected for a statement. The optimizer makes that decision using the information available at compile time: statistics, indexes, cardinality estimates, parameter values and other conditions that can influence the plan.

An estimated plan shows that compiled strategy without running the query. An actual execution plan adds information from the execution itself, including actual row counts and, depending on the plan and SQL Server version, other runtime details. Microsoft explains the distinction in its documentation on displaying and saving execution plans.

For troubleshooting, I usually prefer the actual plan because I can compare what SQL Server expected with what it really processed. If SQL Server expected a few rows but processed several hundred thousand instead, that is worth investigating. The mismatch may affect join choices, memory requirements or the amount of work performed further up the plan.

But the difference itself is not yet a diagnosis. I still need to know whether it helps explain the slow execution I am investigating.

Parameter-sensitive workloads change the picture

This becomes especially relevant with parameter-sensitive workloads. A stored procedure may use the same cached plan for one parameter value that returns ten rows and another that returns several hundred thousand. The plan shape can remain almost unchanged while the actual workload is very different. Data distribution can make that difference larger, and so can changes in the surrounding workload. A plan that works perfectly well for one execution can be much less suitable for another without looking obviously broken when viewed in isolation.

The same caution applies in the other direction. A scan, a warning or a high estimated cost may look uncomfortable, but none of those things automatically explains the incident. A scan against a small table may be entirely appropriate. An expensive operation that runs once at night may matter less than a small query executed thousands of times during business hours.

What I am trying to establish is not whether the plan contains something that could be improved. On a sufficiently busy SQL Server, I can usually find something. I want to know whether the plan explains the behavior that actually caused the problem.

The surrounding workload changes what the plan means

A query can use the same execution plan and still take very different amounts of time.

Another transaction may block it. Storage latency may increase. CPU pressure can come from unrelated activity, while several normally harmless queries may start running at the same time and compete for the same resources. None of that necessarily changes the plan shape.

This is one reason I do not like looking at SQL Server execution plans completely on their own during a production incident. The plan shows what SQL Server intended to do with the query, but elapsed time also includes waiting. If the query spent most of that time waiting for a lock or for storage, tuning an operator may solve the wrong problem.

Wait statistics can help here because they add another view of what SQL Server was waiting for. They have the same limitation, though: they are evidence, not a diagnosis on their own. I wrote about that in SQL Server Wait Statistics Are Not a Diagnosis.

This is also where the timing of the investigation becomes important. If I have an actual plan from the affected execution, together with runtime metrics and information about blocking or resource pressure at the same time, the pieces can start to support each other. If I only have a plan captured later, I have to be much more careful about what I conclude from it.

That is often the difference between finding a plausible tuning opportunity and actually explaining an incident.

When SQL Server execution plans need history

Teams often investigate SQL Server performance problems after the interesting part has already happened.

The application was slow earlier in the morning. Users complained, perhaps monitoring raised an alert, and by the time someone starts looking closely everything appears normal again. CPU is back at its usual level, the blocking chain has disappeared and the query that supposedly caused trouble now finishes quickly.

At that point, current SQL Server execution plans can tell me how the query behaves now. What I really need is a way to compare the current behavior with the period where the problem existed.

Looking back with Query Store

Query Store helps with exactly that. It keeps query texts, execution plans and aggregated runtime statistics over time, which makes it possible to look back instead of relying only on what I can reproduce at the moment of investigation. Microsoft describes the collection process in How Query Store Collects Data.

I may find that the query changed plans shortly before duration increased. That does not prove the new plan caused the regression, but it gives me something concrete to investigate. I can compare both plans, look at the affected runtime intervals and see whether the timing fits.

Sometimes the more interesting finding is that the plan did not change at all.

If Query Store shows the same plan before, during and after the incident, forcing a different plan becomes much harder to justify. I would start looking more closely at the parameter values used during the slow period, concurrency, blocking or resource pressure. The unchanged plan does not tell me what the cause was, but it removes one attractive explanation from the top of the list.

That historical perspective is the reason I consider Query Store so useful in production troubleshooting. I covered that in more detail in SQL Server Query Store: Why Performance History Matters.

Without history, it is very easy to compare a bad user experience from 10:00 with a perfectly healthy execution from 11:00 and assume both represent the same situation.

They may not.

Before I change production, I want the story to make sense

A performance investigation eventually reaches the point where someone wants to change something. Maybe an index is missing. Maybe a different plan would work better. Perhaps a query needs to be rewritten, or a temporary mitigation is required because the application is already affected.

During an active incident, restoring service can take priority. There are situations where I will make a reversible operational change before I understand every detail of the root cause. That is different from deciding what the permanent fix should be.

Permanent tuning changes have consequences. An index helps reads but also affects writes and consumes storage. A hint limits the optimizer’s choices. A forced plan can stabilize a regression and later become a problem itself when the data or workload changes.

Before I make that kind of change, I want the evidence to fit together reasonably well. The plan should match the execution I am trying to explain, and the runtime behavior should support the hypothesis. Timing matters too. If historical data is available, I also want to know whether the behavior was unusual or simply normal workload seen at an inconvenient moment.

That does not require perfect certainty. Production troubleshooting rarely gives us that.

It does require enough context that I can explain why I expect the change to address the actual problem rather than merely improve something that looked suspicious in the plan.

For me, that is where SQL Server execution plans are most useful. They narrow the investigation, show me where SQL Server’s decisions deserve a closer look and give me something concrete to compare against runtime behavior and history.

They are strong evidence, but rarely the whole story.

Foto von David Kristianto auf Unsplash

The post SQL Server Execution Plans Need Runtime Context appeared first on CraftedSQL.

If a restore test only needs to prove that SQL Server can restore a backup file, reaching ONLINE may answer the immediate technical question. When the goal is to demonstrate recovery of a business-critical service, however, the database state provides only part of the evidence. Stopping the test at that point can create more confidence than the result really supports.

Backup and recovery are often discussed as though restoring the database marks the end of the process. From a SQL Server perspective, that may be true, but operationally the more useful question is what the organization can actually use once the restore has finished.

A successful restore proves something important, but not everything

The first task of a restore test is practical: confirm that the available backups can recreate the database. A backup job may run successfully for months and produce valid-looking backup files. Even so, it does not provide the same evidence as restoring those files under controlled conditions.

Depending on the recovery requirement, the technical validation may also confirm the expected backup chain and check the resulting database state. It may also need to establish which point in time the restore has recovered. Microsoft documents the SQL Server restore and recovery process in detail, although those technical steps still answer questions about the database rather than the service that depends on it.

The operational part begins once SQL Server has completed its work, because an application rarely depends on a restored database alone. It also needs to find the SQL Server instance, authenticate correctly and interact with the other components the workload requires.

That is where the difference between database restored and service recovered becomes visible.

The database is part of a larger dependency chain

Some dependencies an application needs do not live inside the restored database at all. SQL Server logins, SQL Agent jobs, credentials, linked servers and instance-level configuration may matter. Application configuration, certificates, DNS, network access or external services can introduce further dependencies outside SQL Server.

This does not mean that every restore test should become an exhaustive inventory of every possible server object or infrastructure component. The useful question is narrower: which dependencies does this particular service require, and does the recovery design include them?

During normal operation, many of those relationships remain largely invisible because everything is already in place. A recovery makes them much easier to see, especially when the database is technically available but the application still cannot use it.

Restore testing therefore provides value beyond validating the backup itself. It also shows how well the organization understands the system and the dependencies needed to bring it back into use.

Application connectivity deserves its own validation

A common gap appears when the database team checks the restored database, but nobody tests the application against the recovered environment. From the SQL Server side, everything may look reasonable: the database is online, queries run and the expected objects exist. None of those checks proves that the application can establish its own connection and perform the work for which the database exists.

Authentication may behave differently on the recovery system. A connection string may still reference another server, a required login may be missing or mapped incorrectly, or a network dependency may differ from production. In each case, the restore can succeed technically while the service remains unusable.

For a simple application, proving service availability may require little more than connecting through the application and executing a known function. In a more complex environment, the database team may not be able to make that judgement alone. Application support or a business owner may need to confirm that the relevant workflow behaves as expected.

The point is not to prescribe one universal test. Someone needs to validate the recovered environment from the perspective of the service, rather than only from the perspective of SQL Server.

The right database can still contain the wrong data

Another distinction appears when the database itself is healthy, but the restored point in time does not meet the business requirement.

A database can restore successfully and pass technical checks while still leaving the organization with more data loss than it intended to accept. Suppose the most recent usable recovery point is several hours old, while the agreed recovery point objective allows only a much smaller gap. In that case, the restore worked, but the recovery objective did not.

This is where RPO becomes operational rather than theoretical. The relevant question is not simply whether the organization can restore data. It also needs to know which data would actually be available after a realistic failure and whether that recovery point is acceptable for the affected process.

Backup frequency, transaction log backups, retention and the availability of the required backup chain all influence that result. Effective SQL Server restore validation should therefore make the recovered point in time visible. The database state alone does not prove that the recovery requirement has been met.

Otherwise, the technical team may correctly report that the restore succeeded, while the application owner later discovers that the available data is older than expected.

Recovery time does not stop when RESTORE finishes

The same distinction applies to recovery time, because the SQL Server restore represents only one part of the time needed to return a service to use. A useful SQL Server restore validation process should therefore measure more than the restore operation itself. Application checks, dependency validation and operational approval may add significant time before the service can resume.

A restore operation is easy to measure because it has a clear start and finish. Suppose the database takes 35 minutes to restore, but the teams then need another hour to resolve dependencies and reconnect the application. They may also need to validate the data and approve the return to service. In that case, 35 minutes remains useful technical information, but it is not the effective service recovery time.

For business continuity planning, the meaningful endpoint is the moment when the required service can actually resume. Reaching that point may involve several teams. Infrastructure may provide the platform, the DBA may restore and validate the database, and application support may verify connectivity and behaviour. The business owner may still need to decide whether the recovered state is acceptable.

When teams have never tested those handoffs, the organization may know how long SQL Server needs for a restore. It still may not know how long the complete recovery really takes.

Recovery needs a defined end condition

That leads to one of the less technical questions in the process: who decides that recovery is complete?

The DBA can confirm a successful database restore and verify that SQL Server sees the database as available. Infrastructure can confirm that the server and network work as expected, while application support can verify connectivity and application behaviour. Depending on the system, a business owner may also need to confirm that the recovered data and the relevant workflow are acceptable.

No universal division of responsibility fits every environment, nor does one need to. The boundary should simply be understood before an incident occurs. If every team considers its own technical task complete without a shared definition of the final outcome, several successful individual steps can still leave the service unavailable beyond the required recovery time.

A useful restore test therefore needs an operational end condition. Instead of ending with “the database is ONLINE,” the test should establish that the required data is available and the application can use it. The relevant dependencies also need to be in place, and the responsible people need enough evidence to return the service to operation.

That provides a different level of assurance, because it describes an operational outcome rather than a database state.

What SQL Server restore validation should actually prove

Backup strategy and restore validation are sometimes treated as separate administrative topics, although they address the same recovery question. Backup frequency, retention, protected storage, monitoring and transaction log handling exist because the organization expects to recover something from them when needed.

Restore testing allows the organization to test those assumptions against an actual outcome.

Can the team locate and access the required backups? Does the necessary backup chain exist, and can the team restore the database away from the original system if necessary? Are the important dependencies known? Can the application use the recovered database, and does the resulting recovery point meet the requirement?

Those questions provide more useful evidence than a green backup job alone. They connect the technical backup process to the service it is meant to protect.

The earlier CraftedSQL article SQL Server Backup Strategy: Why Successful Backups Are Not Enough looked at this from the backup side. Restore validation provides the corresponding recovery perspective: the backup process becomes much more meaningful once the organization has evidence of what it can actually recover from it.

The test should reflect the service you are trying to recover

No single restore-validation procedure fits every SQL Server environment, because recovery requirements differ substantially. A reporting database that may remain unavailable for several hours does not need the same validation process as an operational system with stricter recovery requirements. A self-contained application also has a different dependency chain from a service that spans several databases, interfaces and infrastructure components.

Good SQL Server restore validation therefore starts with the expected recovery outcome rather than with a generic checklist. What must be available again, and how much data loss can the organization accept? Which dependencies are required? Who can verify that the application works, and who is responsible for releasing the service back into operation?

Once those questions are clear, the team can test the restore process against them. That makes it much easier to define what a successful recovery test actually means.

A database reaching ONLINE remains an important milestone, but it is not the same thing as having recovered the service that depends on it.

Foto von Hyoshin Choi auf Unsplash

The post A Restored Database Is Not the Same as a Recovered Service appeared first on CraftedSQL.

At that point, the reason is probably known, and there may even be a ticket, a project document or someone who can explain exactly why the access is required. The problem tends to appear much later, after applications have changed, projects have ended and the people involved have moved to different roles, while the permissions created along the way have remained untouched.

The SQL Server still works, the application continues to run and nobody reports a security problem, so there is little operational pressure to revisit those decisions. Over time, however, the environment accumulates access that may still be technically valid while the context behind it slowly disappears.

That is where permission reviews become more interesting than simply finding accounts with elevated privileges.

The permission itself does not explain why it exists

The SQL Server permissions model gives us enough metadata to build a reasonably detailed picture of access across an instance. We can inspect server and database principals, role memberships, direct grants and Windows groups, then identify accounts that appear unusually powerful or whose purpose is unclear. Microsoft documents the relevant principals, roles and catalog views in its Database Engine permissions documentation.

That inventory is useful, but it is only the starting point because the technical configuration rarely tells the whole story. A login may have broad access because a current application genuinely needs it, or because somebody granted those permissions during a migration six years ago and nobody ever revisited the decision afterwards.

From the permission alone, those situations can look almost identical.

When I review an established SQL Server environment, I therefore want to understand more than which login belongs to which role. I want to know what uses the access today, who owns the corresponding application or process, and whether the current privilege level still matches the technical requirement.

In environments that have been running for many years, answering those questions can be considerably harder than producing the permission inventory itself. SQL Server permissions have a habit of surviving organizational and technical changes much longer than the documentation that once explained them.

Reviewing old SQL Server permissions needs context, not assumptions

The age of a login or permission is useful information, but it is not evidence that the access is obsolete.

An account may belong to an application that was retired years ago, in which case removing it may be straightforward once that dependency has been confirmed. Another account may appear equally old and equally unfamiliar, yet still belong to an integration that runs once a month, a maintenance process that is used only occasionally, or a component that becomes relevant during recovery.

A short observation period will not necessarily reveal those dependencies, and neither will the fact that nobody immediately recognizes the account name.

That creates an uncomfortable but important distinction. “Nobody knows what this account does” should trigger an investigation, but it should not automatically trigger a DROP LOGIN, just as uncertainty should not become a reason to preserve unexplained privileged access indefinitely.

Both approaches create risk.

Leaving unnecessary administrative access in place increases the security exposure of the environment, while removing access without understanding the dependency can turn a security cleanup into an availability incident. A useful permission review therefore has to deal with both sides of that problem rather than optimizing for the shortest possible findings list.

Reconstructing the dependency before changing access

Once an unusual permission has been identified, I would start reconstructing the context around it. Is the account associated with a person, an application, a SQL Server Agent job, a Windows service or another technical process? Is there evidence that the access is still used, and can somebody identify an owner who is able to confirm what that process actually requires?

If the original documentation is missing, the answers may have to come from several places, including job ownership, service configurations, Windows group memberships, application settings or authentication activity. The exact investigation depends on the environment, but the objective remains the same: gather enough evidence to distinguish required access from access that merely survived.

An account that cannot yet be classified should remain visible as an unresolved finding. Lack of context is itself an operational problem because it means that nobody currently has enough information to make a safe decision about that part of the system.

In practice, permissions are often only one part of a broader SQL Server security review. Service accounts and administrative access can expose the same underlying problem from another direction: access still exists, but the reason for it is no longer sufficiently understood.

Why service accounts complicate SQL Server permissions reviews

Service accounts are a good example because they can remain unchanged for much longer than the people who originally configured them.

An account may have been created during the first deployment of an application, received additional privileges during a later migration and then continued running quietly through several upgrades. Years later, the application is still business-critical, but nobody can explain whether all of the SQL Server permissions accumulated by its service account are still necessary.

Sometimes the answer is straightforward once the application owner becomes involved. In other cases, the account has become part of a chain of technical dependencies that crosses SQL Server, Windows services, scheduled tasks and application components, which makes a seemingly simple permission change much harder to evaluate safely.

This is why the privilege level alone does not tell me enough.

If a service account has broad access, I want to know what would stop working if that access were reduced and whether the answer is based on current knowledge rather than on fear of touching an old system. Microsoft also recommends running SQL Server services with the lowest possible user rights and avoiding unnecessary additional permissions for service accounts; the details depend on the service and account type, but the underlying principle is clear. See Configure Windows Service Accounts and Permissions for the current Microsoft guidance.

If nobody can explain what the service account actually requires, the permission problem is accompanied by a second problem: the organization has lost part of the operational knowledge needed to change the system safely. That does not make the current access acceptable, but it changes the next step because the dependency first has to be understood well enough that the change can be controlled.

Least privilege is also a production change

The principle of least privilege is simple enough: an account should have the permissions it requires and no more. Applying that principle to a production environment that has grown organically for ten or fifteen years is less simple because reducing permissions changes something that another component may depend on.

For significant permissions, I therefore treat remediation like any other production change. Before removing or reducing access, I want to understand the expected dependency, know how the result will be validated and have a realistic rollback path if the assumption turns out to be wrong.

The amount of effort should match the possible impact. Removing an obsolete user from an unused development database does not require the same level of preparation as changing the account behind a business-critical application, but both changes should be based on more than the appearance of a permission in a report.

This is also where some security reviews become less useful than they could be.

A large findings list creates visible activity, yet it does not necessarily tell the organization what should happen next. If twenty accounts are marked because they are old, another ten because they have direct grants and several service accounts because they appear highly privileged, the technical observations still need to be translated into priorities.

An undocumented account with server-wide administrative privileges deserves different attention from an old database user with limited access to a non-production database. Likewise, a service account supporting a critical workload may require more careful investigation than several obviously obsolete logins whose dependencies have already been ruled out.

Age matters, privilege matters and scope matters, but so do workload importance, current usage and the ability to explain why the access still exists.

A useful review should lead to decisions

At the end of a SQL Server permissions review, I do not expect every account to fall into the same category.

Some permissions will be appropriate and can remain unchanged. Others will still be required, although the current privilege level is broader than necessary and should be reduced. Some accounts will turn out to be obsolete and can be prepared for removal, while another group will require further investigation because the available evidence is not yet good enough for a safe decision.

That last group should not be hidden simply because it makes the review look unfinished. In a mature environment, identifying where operational knowledge is missing can be just as useful as identifying an excessive grant, because it tells us where future changes are likely to carry unnecessary uncertainty.

For the important accounts, the review should eventually make three things clear: why the access exists, whether the current permissions are still justified, and who is responsible for that decision.

Once those questions can be answered, changing the technical configuration is usually the easier part.

This is why historically grown permissions concern me more than many newly granted ones. A recent change normally still has context around it, whether that is a ticket, a project, a deployment or simply somebody who remembers why the decision was made.

Older permissions may have survived several generations of applications, administrators and operating procedures while continuing to work exactly as they always did.

The access did not disappear.

The knowledge around it did.

And when privileged access can no longer be explained, that is a good reason to investigate it before either blindly accepting it or blindly removing it.

Foto von Toolmash Expo auf Unsplash

The post When Permissions Outlive Their Context in SQL Server appeared first on CraftedSQL.

What made the event particularly useful was the combination of technical content and direct conversations with speakers, DBAs, consultants and other data professionals.

I had also submitted sessions for Data Saturday Rheinland myself. Although I attended as a participant this time, I was prepared to step in at short notice when one of the scheduled speakers had to cancel.

In the end, the organisers found another replacement, but being available was important to me. Community events depend on people who are willing to contribute, whether through a planned session, an informal discussion or by helping when the original agenda can no longer be maintained.

That also changed my perspective on the event. I was not only there to consume content. I had prepared topics of my own, was ready to speak and paid close attention to how other speakers structured their sessions, explained technical details and interacted with the audience.

Eight hours of PostgreSQL for SQL Server DBAs

The event started on Friday with Grant Fritchey’s full-day pre-conference session:
What a SQL Server DBA Needs to Know About PostgreSQL

For someone who has spent many years working primarily with SQL Server, PostgreSQL is an interesting subject for several reasons.

More organisations are using multiple database platforms. Applications are no longer automatically built on one preferred relational database system, and SQL Server professionals increasingly encounter PostgreSQL in migrations, cloud environments or mixed technology stacks.

That does not mean that every SQL Server DBA needs to become a PostgreSQL specialist. It does mean that we should understand the main differences.

Administration concepts, configuration, indexing, execution plans, maintenance and troubleshooting may look familiar at first, but the underlying behaviour and operational assumptions are not always the same.

An eight-hour session provided enough time to move beyond a simple feature comparison. It allowed Grant to explain where SQL Server experience transfers well, where it can create false assumptions and which PostgreSQL concepts require a different mental model.

That distinction matters. Familiar terminology can sometimes be more dangerous than completely unfamiliar technology because it encourages us to assume that two systems behave in the same way.

Saturday at Data Saturday Rheinland 2026

Saturday offered several sessions that approached data platforms from very different directions.

GenAI and data literacy

Marco Nielinger presented:

GenAI for Data & Analytics: What’s Hot and What’s Not?

Generative AI is currently included in almost every technology discussion, but the practical value varies considerably between use cases. Sessions like this help separate capabilities that can already support real work from ideas that are still mainly demonstrations, experiments or marketing.

Oliver Engels and Katharina Ricken discussed:

Building Data Literacy in the Microsoft Data Platform Era

Technical platforms alone do not solve data problems. An organisation may have modern tools, centralised data and sophisticated reporting while users still struggle to interpret information correctly or make decisions from it.

Data literacy is therefore not a side topic. It influences whether investments in analytics and data platforms produce useful results outside the technical teams that build them.

Grant Fritchey returned with:

SQL Server performance and window functions

Query Performance Enhancements in SQL Server 2025

SQL Server 2025 introduces new options and changes that can affect how we analyse and improve query performance. For DBAs and consultants, the relevant question is not merely which features are new. We also need to understand when they apply, what problems they address and how they change existing troubleshooting practices.

New performance features can support diagnosis, but they do not replace the need to connect query behaviour, waits and infrastructure signals. I discussed that distinction in more detail in SQL Server Monitoring Is Not Diagnosis.

Thomas Hütter closed my personal agenda with:

Window Functions in SQL Server: Brush Up Your Skills

Window functions have been available in SQL Server for years, but they are still frequently underused or used without a clear understanding of their behaviour. Revisiting established functionality is often just as useful as learning about a new feature.

A better understanding of existing SQL capabilities can simplify queries, reduce unnecessary processing and make code easier to maintain.

The value is not limited to the sessions

The sessions were interesting, but events like Data Saturday Rheinland offer something that online training, documentation and recordings cannot fully reproduce.

The speakers are physically present.

When a detail is unclear, you can ask immediately. When a demonstration raises another question, you can discuss it directly with the person presenting it. Speakers can explain why they recommend a certain approach, where it has failed and which constraints are often missing from a simplified technical example.

That direct access changes the quality of the conversation.

The same applies to discussions between sessions.

Talking with other DBAs, consultants, service providers and platform specialists gives me a broader view of how other organisations work:

• Which problems are they currently seeing?
• How are they operating their SQL Server environments?
• Which tools and processes have worked for them?
• Where have technically reasonable approaches failed in practice?
• Why did they choose one solution instead of another?

These conversations do not always produce an immediate technical answer. Often, their value is in questioning assumptions.

A configuration or process may appear normal because it has been used in the same organisation for years. Meeting people from other environments provides a useful comparison. They may solve the same problem differently, face constraints you have never encountered or have already tested an approach you are only beginning to consider.

Community events remain relevant

Most technical information is available online. Documentation, conference recordings, blogs and training platforms make it possible to learn almost anything without travelling to an event.

But access to information is not the same as access to experience.

An in-person community event creates room for follow-up questions, disagreement, practical examples and conversations that were not planned as part of the official agenda.

Having submitted sessions myself and being ready to step in also reminded me that these events only work because people contribute their time, experience and willingness to help.

For me, that remains one of the strongest reasons to attend.

Data Saturday Rheinland 2026 offered strong speakers, relevant topics and plenty of opportunities to exchange experiences with people working on similar problems from different perspectives.

I returned with new technical input, a better understanding of several topics and, equally important, new questions to follow up on.

That is a good result from two days at a community event.

The post What I Took Away from Data Saturday Rheinland 2026 appeared first on CraftedSQL.

This matters because AI does not run in isolation. Once AI systems move closer to real business workflows, the surrounding platform becomes decisive: the data, the permissions, the integration paths, the observability, and the operational model behind it.

Agentic AI is often discussed through demos, assistants, and automation scenarios. But the more relevant question for database and infrastructure professionals is what has to be in place before those scenarios become reliable in production.

Behind every impressive AI workflow, there is still a less visible foundation: data quality, permissions, latency, integration, cost control, observability, and operational discipline.

The interface may become more intelligent. The underlying systems still have to be trustworthy.

Agentic AI data platforms change the conversation, but not the fundamentals

The term “Agentic AI” was clearly central to the event narrative.

That is not surprising. The industry is moving from AI systems that answer questions toward systems that can plan, call tools, interact with applications, and execute tasks within defined boundaries.

From a business perspective, that sounds powerful. From an operational perspective, it immediately raises harder questions.

• What data is the agent allowed to access?
• Which systems can it interact with?
• How are decisions logged?
• Who owns the outcome if an automated action is wrong?
• How do we test the behavior before it touches production processes?

These are not new concerns. They already exist in data platforms, integration systems, database operations, and enterprise applications. Agentic AI simply makes them harder to ignore.

An agent that works with weak data will produce weak decisions faster. An agent with unclear permissions becomes a security risk. An agent connected to unreliable systems will amplify operational noise. And an agent without observability becomes another black box in an already complex environment.

The AI layer may be new. The operational discipline behind it is not.

The data layer is still where reality starts

For database professionals, one of the most relevant takeaways is that Agentic AI data platforms do not reduce the importance of structured, trustworthy data.

It increases it.

Large language models can reason over text, summarize information, and generate responses. But enterprise use cases usually depend on something more concrete: customer records, transactions, policies, logs, telemetry, inventory, financial data, operational workflows, and business rules.

That data lives somewhere.

Often it lives in relational databases. Sometimes in data lakes, warehouses, search indexes, queues, APIs, or application-specific stores. In real environments, usually in a mix of all of them.

This is where the practical work begins.

Before an AI system can support decisions, the organization needs to know which data is authoritative. Before an agent can automate a process, the boundaries of that process need to be understood. Before analytics can support strategy, the underlying data model must be stable enough to trust.

This is not only an AI problem.

In practice, it is a data platform problem. In many companies, it is still very much a database operations problem.

From dashboards to actions

One of the more interesting shifts in the AI discussion is the move from showing information to helping people act on it.

That sounds small, but it changes the responsibility of the platform.

Traditional dashboards visualize signals. Monitoring tools raise alerts. Reports show trends. Query tools expose data. But in many environments, the difficult part is not seeing that something happened. The difficult part is understanding what it means and deciding what should happen next.

This is already familiar in database operations.

A dashboard can show high CPU. That does not explain whether the cause is a missing index, parameter-sensitive execution, parallelism, memory pressure, storage latency, bad application behavior, or a reporting workload running at the wrong time.

A monitoring system can show blocking. That does not automatically explain whether the real problem is transaction design, isolation level, missing indexes, deployment behavior, or application retries.

AI can help connect signals, context, and possible next steps. But only if the platform provides enough reliable context, and only if recommendations stay within clear operational guardrails.

The value is not in replacing expertise. It is in reducing the gap between signal and diagnosis.

This is also why monitoring alone is not enough. Signals only become useful when they are connected to diagnosis, context, and operational decisions. I covered this distinction in more detail in SQL Server Monitoring Is Not Diagnosis.

Cloud platforms are becoming control planes

AWS Summit Japan also showed how cloud platforms are increasingly positioning themselves as operational control planes.

Infrastructure, application runtime, data services, AI services, security, monitoring, cost management, and automation are no longer separate conversations. They are being connected into broader platform stories.

For SQL Server and database professionals, this is worth watching closely.

Even if a system remains on-premises or runs outside AWS, the direction is clear: organizations expect more automation, more integration, more observability, and faster feedback loops. They expect platforms to reduce manual work, not only host workloads.

But there is a risk.

A more automated platform is not automatically a better-operated platform.

If the underlying architecture is fragile, automation can make failure faster. If data ownership is unclear, AI can make confusion more scalable. If monitoring is noisy, agents may simply produce more noise. If cost visibility is weak, cloud-native architectures can become expensive before anyone notices.

The operational model has to mature together with the technology.

What this means for SQL Server environments

At first glance, an AWS Summit may seem far away from day-to-day SQL Server work.

The connection is stronger than it appears.

Many SQL Server environments are still at the center of critical business processes. They hold transactional data, operational history, reporting structures, application state, and years of accumulated business logic. Even when new cloud services and AI tools enter the architecture, those systems do not simply disappear.

They become part of the data supply chain.

That means classic database topics remain highly relevant:

• Performance still matters, because AI-driven workflows often depend on timely access to data.
• Security still matters, because agents and automation increase the importance of permissions and auditability.
• High availability still matters, because intelligent workflows do not help when the authoritative data source is unavailable.
• Data modeling still matters, because poor structure creates ambiguity downstream.
• Observability still matters, because automated decisions require traceable inputs and measurable outcomes.

The future does not remove the need for database expertise. It changes where that expertise connects.

A SQL Server specialist does not need to become an AI researcher. But it becomes increasingly useful to understand how databases, APIs, analytics layers, event-driven systems, and AI services interact in real architectures.

That is where many future troubleshooting and architecture questions will appear.

The uncomfortable truth: AI depends on boring reliability

The most important takeaway is also the least fashionable one: Agentic AI depends on boring reliability.

• Stable platforms.
• Clear data ownership.
• Good logging.
• Sensible permissions.
• Known recovery paths.
• Cost awareness.
• Operational discipline.
• People who understand what happens below the interface.

This is not the language of hype, but it is the language of production.

The more AI moves into business workflows, the more important it becomes to understand the systems that provide the context, execute the actions, and store the results.

That is where databases still matter.

Not because every future system will be built around a relational database. But because every serious business system still depends on reliable state, trustworthy data, controlled change, and operational accountability.

Looking beyond the SQL Server ecosystem

For a SQL Server-focused consultancy, events like AWS Summit Japan are useful because they widen the perspective.

They show where the broader platform market is moving. They make visible how cloud providers frame AI, infrastructure, analytics, developer experience, and operations as connected topics. And they help separate short-term excitement from the structural changes that are likely to affect real environments.

The practical conclusion is simple: AI will not make database operations irrelevant. It will make weak data platforms harder to hide.

Organizations that want to use AI seriously will need more than models and demos. They will need reliable systems, understood data flows, clean operational boundaries, and people who can diagnose what is happening when the abstraction leaks.

That is not new work. But it is becoming more visible.

And for those working close to databases and production systems, that may be the most important signal behind the current wave of Agentic AI data platforms.

The post AWS Summit Japan 2026: Agentic AI, Data Platforms, and the Operational Reality Behind the Hype appeared first on CraftedSQL.

The date matters, but it is only the visible boundary. In many environments, the real risk starts earlier: when nobody has a reliable overview of affected systems, dependencies, ownership, business criticality, and realistic options. SQL Server 2016 is often not critical because it suddenly stops working. It becomes critical because the organization loses room to act.

A database server does not fail automatically because a support date has passed. Applications may continue to run, jobs may still complete, backups may still succeed, and monitoring may still look normal. As with many SQL Server issues, visible symptoms do not always reveal the underlying operational risk.

That is what makes this topic easy to underestimate. The technical surface can look stable while the operational risk changes underneath.

SQL Server 2016 EOL Is Only the Visible Boundary

End of Support does not mean that SQL Server 2016 becomes unusable the next morning. It means that the regular support lifecycle ends and that organizations need a deliberate path forward. That path may involve an upgrade, a migration, Extended Security Updates, temporary continued operation with accepted risk, or a combination of several measures across different systems.

Extended Security Updates can be a valid transition mechanism, but they should not be confused with a target state. Microsoft describes Extended Security Updates for SQL Server as protection for up to three years after the support lifecycle ends. They do not include new features, functional improvements, or customer-requested fixes. ESU can buy controlled time, but it does not replace a decision about the future of the affected systems.

That distinction matters. ESU can be useful when organizations treat it as a bridge with a clear plan. When they treat it as the plan itself, it may simply extend the period of indecision.

The weaker question is: Can we keep SQL Server 2016 protected for a while longer? The better question is: Which decision are we making for each affected system, and by when can we realistically implement it?

In Real Environments, the Pressure Rarely Comes from SQL Server Alone

Lifecycle discussions often move too quickly toward target versions, migration paths, or cloud options. That is understandable, but often premature. In real production environments, the limiting factor is rarely SQL Server alone. The pressure usually comes from applications, dependencies, testing constraints, maintenance windows, vendor support, licensing, ownership, and business risk.

A SQL Server instance may look technically upgradeable until someone discovers that an old business application is only certified for a specific SQL Server version. In other cases, no one knows exactly which jobs, linked servers, reports, interfaces, or batch processes depend on that instance. Sometimes the blocker is even simpler: there is no realistic test environment where an upgrade can be validated properly.

In that situation, “upgrade to a supported version” may be technically correct, but operationally incomplete. Changing the SQL Server version is only part of the work. The harder part is restoring decision capability.

Organizations need to answer basic but uncomfortable questions: Which instances exist? Which databases are business-critical? Which applications depend on them? Who owns the application? Who owns the risk? Which downtime is acceptable? Which systems can be consolidated, replaced, isolated, or moved? Which ones need short-term protection, and which ones need a proper modernization path?

Without that clarity, every technical recommendation remains weaker than it looks. This is similar to practical SQL Server troubleshooting, where separating SQL Server symptoms from underlying causes helps avoid working in the wrong layer.

“It Still Runs Fine” Is Not an Operating Strategy

One of the most common mistakes with older SQL Server versions is confusing stability with acceptability. Of course, a SQL Server 2016 system can still run well. Many do. Some teams maintain them carefully, back them up properly, monitor them consistently, and rarely see visible incidents.

That should not be dismissed. Stable systems often exist for good reasons, especially in environments with long-lived applications, strict change windows, vendor constraints, or complex dependencies. But past stability is not the same as future readiness.

After End of Support, the risk context changes. Security posture, audit discussions, vendor support, internal compliance, customer requirements, insurance expectations, contractual obligations, and the willingness of external service providers to take responsibility for changes can all shift. Depending on the environment, those factors may matter more than whether the database engine appears stable today.

This does not mean that every SQL Server 2016 system must be migrated immediately. That would be too simplistic. It means that every affected system needs an explicit decision, because documented, risk-aware temporary continuation is very different from silent continuation because nobody had time to deal with the issue.

There Is No Single Correct Answer

For SQL Server 2016, there are several realistic paths. The right one depends on workload, application support, criticality, licensing, infrastructure, business tolerance, and available time. An upgrade to a supported SQL Server version may be the most direct option when the application is compatible, the environment is documented, and testing can be done properly. It reduces lifecycle risk without necessarily changing the entire operating model.

A migration or partial modernization may make sense when infrastructure decisions are already pending, when hardware or data center topics are involved, or when selected workloads fit better into another operating model. Organizations should still make that decision deliberately. Cloud is not an automatic escape from missing planning.

Extended Security Updates can be a pragmatic transition mechanism when the target decision has already been made but implementation needs more time. The important word is transition. Without a target date and clear ownership, ESU can become a paid extension of the same problem.

Some cases may also justify temporary continued operation with documented risk. That should not happen by accident. It needs a conscious assessment of criticality, exposure, compensating controls, backup and restore capability, monitoring, access protection, and a planned retirement or migration point.

Still running SQL Server 2016 is not always the dangerous option. The real danger is running SQL Server 2016 without being able to explain why, for how long, under which controls, and who accepted the risk.

What Needs to Be Decided Now

The first operational step is not migration. The first step is visibility. For SQL Server 2016 EOL, visibility matters more than choosing a target platform too early. Without a clear inventory, organizations are not deciding between realistic options. They are guessing under time pressure.

An organization needs to know which SQL Server 2016 instances exist, which editions are used, which patch levels are installed, which databases are hosted, which applications connect to them, and which systems are business-critical. Without that inventory, any discussion about upgrade, migration, ESU, or risk acceptance remains incomplete.

After that, each affected system needs classification. Is this system business-critical? Is the application still supported? Is there a test environment? Is an upgrade technically and organizationally realistic? Is ESU required to buy time? Is there a clear target date? Who owns the decision? Who accepts the remaining risk?

These questions look simple, but in real environments they are often exactly where projects slow down. Not because SQL Server is impossible to upgrade, but because the database platform has become part of a larger operational structure that nobody fully mapped for years.

The Real Risk Behind SQL Server 2016 EOL Is Delayed Decision-Making

SQL Server 2016 End of Support is an important date, but it is not the core problem. The core problem is delayed decision-making. The later an organization understands which systems are affected and which path is realistic for each of them, the less room it has for controlled action. What could have been a planned lifecycle topic turns into a risk, budget, audit, and priority discussion under time pressure.

Panic is the wrong response. A reflexive “move everything to the cloud”, “buy ESU”, or “upgrade everything immediately” is not much better. A better response starts with a clear inventory, a realistic assessment, and a documented decision per system.

When organizations handle SQL Server 2016 EOL properly, it can still remain a controlled lifecycle topic. When they handle it too late, it becomes an operational risk discussion with fewer options and less time.

An old SQL Server system is not automatically a bad system. It becomes a serious operational risk when nobody can explain why it is still running, what depends on it, how it is protected, who accepted the risk, and when the next decision will be made.

If SQL Server 2016 is still part of your production environment, the first useful step is not choosing a target platform. It is building a clear inventory, understanding dependencies, and making a documented decision for each affected system.

The post SQL Server 2016 End of Support: The Real Problem Is Not the Date appeared first on CraftedSQL.

This becomes especially relevant for SQL Server 2016. On July 14, 2026, extended support for SQL Server 2016 comes to an end. From July 15, 2026, organizations that still need more time can move into Extended Security Updates (ESU) Year 1. See the Microsoft Lifecycle Policy for SQL Server 2016.

On paper, that looks like a normal lifecycle milestone. In practice, it is often the moment when older operational decisions become visible again: incomplete inventories, unclear application dependencies, missing vendor statements, undocumented exceptions, and environments that have been running for years but are no longer easy to change.

That is why I do not see SQL Server 2016 end of support as just an upgrade topic. In many environments, it is also a question of whether the organization has enough visibility, ownership, and time left to make a controlled decision instead of reacting under pressure.

What SQL Server 2016 end of support actually means

As long as a product remains in extended support, Microsoft continues to provide security updates. Once that period ends, those regular security updates stop unless the organization moves to an ESU path. Microsoft’s general lifecycle guidance also makes clear that after support ends, customers should no longer expect the regular support model they had before.

That does not mean a SQL Server 2016 instance will suddenly stop working on July 15, 2026. The databases will still start, applications may still connect, jobs may still run, and day-to-day operations may look unchanged at first. But from that point onward, the environment has to be assessed differently.

Security exposure changes. Audit and compliance discussions become more difficult. Vendor and support boundaries matter more. If there is still no clear strategy by then, the pressure to decide usually increases very quickly, and that pressure rarely improves the quality of technical decisions.

The important question is therefore not only when support ends. The more useful question is whether the organization actually knows what it is running, how critical those systems are, and which options are still realistic for each environment.

Why doing nothing is a risk

Many legacy environments have been running “just fine” for years. That can create a dangerous kind of comfort, because a system can be stable in daily operations and still be poorly documented, difficult to change, tied to unsupported application stacks, or understood by only a small number of people.

“It still works” is not automatically wrong as an observation. It becomes problematic when it replaces a real assessment of risk, dependencies, supportability, and change readiness.

In real-world environments, this becomes visible very quickly. Instances are only partially inventoried. Vendor certification for newer SQL Server versions is unclear or missing. What looks like a simple upgrade can sit on top of old interfaces, fragile SQL Agent jobs, linked servers, SSIS packages, special-case integrations, third-party tools, or application components nobody wants to retest under time pressure.

In those situations, the database engine is often not the hardest part of the discussion. The harder part is the accumulated operational context around it: unclear ownership, slow approval paths, inherited assumptions, missing documentation, and decisions that were postponed because the system did not create enough pain in daily operations.

A similar pattern also appears in acute performance incidents. Teams often react to visible symptoms before they understand the underlying cause. I described that pattern in more detail in SQL Server suddenly slow? The 5 most common causes. Lifecycle decisions have a similar risk: if the starting point is unclear, the chosen solution may be technically possible but still wrong for the environment.

That is why the main risk is not only about future security updates. It is also the loss of room for careful decisions. In practice, the better sequence is usually to understand inventory and dependencies first, and only then discuss whether upgrade, migration, Azure, or ESU is the right path.

Four areas to review before SQL Server 2016 end of support

Before talking about upgrade, migration, Azure, or ESU, companies need an honest inventory. In my view, there are at least four areas that should be reviewed properly, because they usually determine whether the next step is realistic or only looks good in a planning document.

1. Which SQL Server 2016 instances are still running?

This sounds basic, but in larger or historically grown estates this is often where the first surprises appear. A server list alone is not enough, especially if it does not include edition, build level, role, business criticality, connected applications, hosting model, backup and monitoring coverage, and current ownership.

What matters is not just whether an instance exists. What matters is whether the available information is good enough to support a decision. A rough technical inventory may help with discovery, but it is not the same thing as a decision-ready view of the environment.

2. What business and technical dependencies exist?

This is where many decisions become more complicated than expected. In practice, the database version is often only one part of the problem. The harder constraints usually sit around it: legacy applications with limited vendor support, operating system dependencies, middleware constraints, old integrations, fragile jobs, linked servers, SSIS packages, reporting components, or third-party tools that nobody wants to retest under time pressure.

This part is underestimated in many organizations. The biggest problem is often not technical feasibility in isolation, but the accumulated dependency footprint around the system. An upgrade may be possible from a SQL Server perspective and still be difficult because the surrounding application and operational model has not been prepared for change.

3. Which SQL Server 2016 end of support option is realistic?

Microsoft outlines the general SQL Server end of support options in its documentation. That overview is useful, but it does not answer the operational question for a specific environment.

The real question is not only: “What options exist?” The more important question is: “Which option is realistic for this system, with acceptable risk, acceptable effort, and within the available time window?”

That difference matters. Upgrade, migration, Azure, and ESU are not interchangeable labels. Each option has consequences for testing, downtime, fallback, licensing, application support, operations, monitoring, security, and long-term maintainability. This is where wishful thinking and planning discipline usually start to separate.

4. Is ESU a valid SQL Server 2016 end of support strategy?

ESU can be a valid option, but only if it is used consciously as a temporary bridge. Microsoft describes the ESU program as a last-resort option and a short-term way to stay protected while moving toward a newer supported platform. Microsoft offers it for up to three years after the end of extended support.

What ESU typically does not solve is just as important. It does not fix poor visibility, weak documentation, outdated architecture, unclear ownership, legacy application constraints, or a lack of testing and migration readiness.

ESU can buy time, but it does not automatically improve documentation, ownership, testing, or migration readiness. Used well, it can support a controlled transition. Used poorly, it can simply postpone the same unresolved decisions into the next budget cycle. For additional details, see the Microsoft Extended Security Updates FAQ.

Upgrade, migration, Azure, or ESU: a more realistic view

One of the most common mistakes is to assume there is one obvious default answer. In reality, the right path depends on the application landscape, infrastructure condition, support requirements, risk tolerance, available time, and the operating model the company wants to support after the transition.

When an upgrade can make sense

An upgrade is often the right choice when the application is supported on a newer SQL Server version, the current platform is still broadly viable, and testing, downtime planning, and fallback are realistic. In many cases, this is the most pragmatic route, especially when the main issue is the SQL Server version itself and not the surrounding architecture. Still, a pragmatic path is not an automatic one; it needs proper preparation, especially where compatibility, maintenance windows, rollback options, application testing, and operational handover matter.

When migration is the better option

A migration can be the stronger decision when the current environment needs more than a version change. That may be the case when infrastructure is already due for replacement, when the existing setup no longer matches availability or security requirements, or when operational processes have moved beyond what the current platform should continue to carry.

This matters because the technically possible route is not always the operationally sensible one. Sometimes the end of support date is not only a deadline, but also a useful point to stop investing effort into a platform layout that should have been replaced anyway.

When Azure is worth serious consideration

Microsoft’s end-of-support guidance explicitly points to Azure-related paths such as Azure SQL Managed Instance, SQL Server on Azure Virtual Machines, and Azure VMware Solution, depending on whether the goal is modernization, near-term relocation, or a more gradual transition.

But Azure is not a shortcut by itself. Questions around application behavior, latency, responsibilities, operations, cost, and migration sequencing still remain. Azure makes sense when it fits how the company wants to operate, monitor, secure, and support the environment afterwards. It is a poor choice when it is selected only as a reflex to an end-of-support deadline.

When ESU is defensible

ESU is defensible when there is a clear target strategy, when the environment cannot be changed cleanly in the short term, and when the transition period is intentionally limited. It can be a reasonable bridge for systems that need more time because of vendor constraints, testing effort, application dependencies, or sequencing with other infrastructure work.

ESU becomes problematic when it mainly covers up delay, uncertainty, or organizational indecision. If there is no defined next step, no ownership, and no realistic timeline, ESU does not solve the core problem. It only makes the unresolved situation look temporarily controlled.

What companies should do before SQL Server 2016 end of support

Organizations still running SQL Server 2016 do not need panic, but they do need structure. A useful first step is not to jump straight into a preferred technology path. It is to build a reliable inventory and ask a small set of hard questions:

1. Which instances are affected?
2. Which applications and business processes depend on them?
3. Which vendor, platform, and operational constraints exist?
4. Which path is realistic per system: upgrade, migration, Azure, or ESU?
5. Where is immediate action required, and where is a managed transition acceptable?

Only once those questions are answered does this become a manageable program instead of a late-stage lifecycle reaction. Without that clarity, organizations often spend too much time discussing the preferred solution and too little time understanding the actual starting point.

Where inventory, dependencies, and realistic next steps are still unclear, structured SQL Server consulting services can help create a practical view of the environment and define the next steps system by system.

Final thought

SQL Server 2016 end of support is not something that can be handled well with a generic “we will just upgrade it” response. The date is clear, but the harder part is what sits behind it: incomplete inventory, unclear dependencies, missing vendor certification, legacy applications, and decisions that were deferred for too long.

Good decisions in these environments rarely depend on the version number alone. They depend on the quality of the inventory, the understanding of dependencies, the ability to prioritize correctly, and an operational logic that looks for the most sustainable path, not just the fastest one.

If SQL Server 2016 is still in use today, the priority is not to decide too quickly between upgrade, migration, Azure, or ESU. The priority is to understand the starting point well enough that the chosen path is realistic, supportable, and defensible in the specific environment.

If you are currently reviewing SQL Server 2016 environments and want an independent second opinion on inventory, dependencies, or realistic next-step options, get in touch.

The post SQL Server 2016 End of Support: What Companies Should Review Now appeared first on CraftedSQL.