No decision from three clicks. But a good preselection from eight questions.
Three parts were about the mechanics of the failover cluster instance (FCI) and the availability group (AG), about the feature matrix, operational consequences and licensing rules. Now it is about your case. The decision guide below asks eight questions about requirements and constraints and then ranks five candidates: FCI, basic AG, full AG, log shipping and, to be perfectly honest, backup and restore without high availability. Each candidate gets reasons for, reasons against and, where there is one, the reason for exclusion. "I don't know yet" is allowed for every question and ends up in a list of what you should clarify. Your answers stay in the browser; nothing is transmitted.
In short
- The tool delivers a ranking with reasons, not a product. Five candidates, each with "speaks for," "speaks against" and "ruled out by."
- Hard exclusions come only from evidenced limits: one database per basic AG, no reading and no backups on the basic AG secondary, one copy of the data with the FCI, full AG only in Enterprise, no automatic failover with log shipping.
- Soft ratings follow part 2: a role change is faster than an instance restart, instance objects travel only with the FCI, and two replicas are not enough for local automatic failover and site protection at the same time.
- "I don't know yet" is a permitted answer, usually the most important one. It appears under "You should clarify this," together with the three points that are open for every option: failover rehearsed, application reconnects, backup tested.
- Nothing leaves your browser. No sign-up, no form, no storage; you can copy the summary and paste it into a ticket or an email.
- High availability is not a backup. Every result ends with this sentence because it holds for every option.
The decision guide
Answer the questions in any order; the result on the right (below on a phone) updates with every answer. Where you are unsure, choose "I don't know yet." Clicking a reason leads to the section of the series it comes from.
How the result comes about
The tool knows two kinds of rules. Hard exclusions take a candidate out of the ranking because an evidenced limit of the option contradicts your answer. Soft ratings shift the ranking because an option meets the requirement more or less easily. Both kinds are shown here so that you can follow the result and disagree with it.
| If you answer … | … is ruled out | because |
|---|---|---|
| Data loss: none | Log shipping, backup without HA | Log shipping transfers log backups at the pace of the jobs, and a backup concept loses everything since the last log backup (part 2, matrix) |
| Recovery: automatic | Log shipping, backup without HA | Log shipping has no automatic failover; the role change is always manual (part 2) |
| Protection: additionally storage or site | FCI | The FCI has one copy of the data on shared storage; only a replicated storage solution covers a storage or site failure (part 1) |
| Databases: several that switch together | Basic AG | A basic AG contains exactly one database; several groups switch independently of one another (part 1) |
| Storage: local disks only | FCI | An FCI needs shared storage: SAN, Storage Spaces Direct or an SMB share (part 1) |
| Copy: read reports | FCI, basic AG | Passive FCI nodes are stopped; the basic AG secondary allows no read access (part 2) |
| Copy: offload backups | FCI, basic AG | There is no second copy, or no backups on the basic AG secondary, respectively (part 2) |
| Edition: Standard, Enterprise not an option | Full AG | The full AG is reserved for Enterprise (part 3) |
The soft ratings in brief: a recovery in seconds speaks for the AG, because the role change was done in under a second in the lab, while the instance restart, the stand-in for the FCI failover, took about ten (part 2). Administration on the side speaks for the FCI, because logins, jobs and configuration move with the instance and, with an AG, have to be maintained on every replica (part 2). Site protection plus local automatic failover is a burden for the basic AG, because its two replicas can be either local and synchronous or asynchronous at the second site, not both (part 1). Hours of data loss and a manual role change strengthen log shipping and the pure backup concept, because both meet the requirement without a cluster. Reports or backups on the copy lead to the full AG and at the same time carry the note from part 3: a readable secondary is not passive and needs its own license (part 3).
What the tool deliberately does not do: it does not calculate costs, it does not assess a contract, and it does not count synchronous replicas, because Microsoft gives that number differently on different pages.
Three typical result patterns
The line-of-business application with one database. One data center, data loss ruled out, automatic recovery within a few minutes, nobody reads on the copy, Standard Edition, administration on the side. Result: FCI and basic AG lead, the FCI usually narrowly ahead because of the instance objects, the basic AG close behind because of the faster role change and the storage protection. The full AG is ruled out, and log shipping fails on automatic failover. Still to clarify: shared storage available, failover rehearsed, application reconnects.
Two data centers, several databases. Local automatic failover and site protection, databases must switch together, Enterprise is possible. Result: the full AG leads, the basic AG is ruled out (one database per group), and so is the FCI without a replicated storage solution. Log shipping remains as a DR supplement. With "Standard, Enterprise not an option" the picture flips: then the standard path is an FCI for local automatic failover plus log shipping to the second site with a manual role change, and the tool says so.
The reports should leave the primary. As soon as you choose "read reports," only the full AG remains, and the result carries the licensing note: the readable secondary is not passive. If you don't want that, you will find the alternatives from part 3 under "to note," such as a separate reporting copy or log shipping with a standby database that is readable between the restores.
What the result is not
It is not an architecture. It does not say how many nodes, which quorum configuration, which witness, which networks. It is not licensing advice: the rules from part 3 apply with source and date, and your contract is what counts. And it does not replace three things that every option needs and that are rarely budgeted in database projects: a failover drill with a measured time to the first successful write, an application that reconnects, and a tested backup, because a secondary takes over every user error within milliseconds.
After the result: the checklist for the conversation
The preselection is the start of the conversation with infrastructure, application owners and purchasing. These eight points should come up in it:
- RPO and RTO in writing, in minutes, with the name of the person who set them. Part 2 shows how to measure both for an AG.
- The list of failures you want to protect against: node, storage, site, user error. No replication helps against the last one.
- The application's database layout: which databases must switch together, which instance objects (logins, jobs, linked servers) belong to them?
- The storage: shared storage available or not, replicated or not, and who runs it.
- The read requirement: who wants to read or back up on the copy, and is the licensing consequence from part 3 known?
- Edition and contract: Standard or Enterprise, Software Assurance or subscription for the fail-over rights, the capacity limits of Standard Edition against the expected load.
- The operations team: who maintains logins and jobs on all replicas, who patches in which order, when is the next failover drill?
- Application and backup: does the application reconnect after a failover? When was the restore last rehearsed?
Frequently asked questions
Why does log shipping appear as a candidate? That isn't high availability. Correct, the role change is manual. But many requirements really mean "second site, loss of minutes acceptable, switching by hand is fine," and for that, log shipping in Standard is the simplest evidenced way. The tool is meant to show that, instead of reflexively recommending a cluster.
Why doesn't the tool ask about the budget? Because prices are not part of this series, and a budget without a requirement doesn't support a decision. The question about the edition covers the part that determines the architecture.
Why is Azure missing? The series compares the two technologies on your own Windows servers. For Azure SQL Database, Managed Instance and SQL Server on Azure VMs, other levers apply; they have their own pages under SQL Server in Azure.
Does the page store my answers? No. The answers live only in the page's memory and are gone after a reload. That is why there is a "Copy summary" button.
What if two candidates are tied? Then that is the honest answer: both meet your requirements, and the decision is made on things the tool can't see: existing hardware, the team's experience, the contract situation. This is exactly the point where an availability review brings more than another click.
If you're facing the decision
With the copied result you have a preselection with reasons. In the availability review of our SQL Server Health Check, we set it next to what your environment achieves today: measured recovery time, log send queues, backup chain, application behavior in a failover. For planning, build and migration, there is our SQL Server High Availability: Design and Build service. We advise without any interest in selling licenses ourselves.
Sources
The rules of this tool rest on the Microsoft references of parts 1 to 3 of this series (checked on Nov 8 and 9, 2026) and on the lab measurements from part 2 (SQL Server 2022 CU27, without a Windows cluster). Every reason in the result links to the section it comes from. The tool names no number of synchronous replicas and no prices.