SQL Server consulting: performance, Always On, upgrades and Azure SQL decisions

How a slow SQL Server workload is triaged, in order

Most slow-SQL-Server work goes wrong because it starts at the symptom a person can see, such as a missing index or a small server. The order below starts at what the engine reports and ends at hardware.

• 1. Waits first — What the instance is waiting on, from its wait statistics, tells us whether the time goes to CPU, I/O, locking or something else. A fix aimed at the wrong wait changes nothing.
• 2. Then the queries behind them — Query Store, available since SQL Server 2016 and on by default for new databases from SQL Server 2022, ranks queries by duration, CPU and reads and shows execution plan changes over time. It turns a vague complaint into a list of statements.
• 3. Plan regressions after a change — A version upgrade or a compatibility level change can change the optimizer's behaviour; the new cardinality estimator arrived with compatibility level 120. We test the new level with Query Store open, and force the last good plan while a regression is fixed.
• 4. Blocking, tempdb and memory — Long transactions, lock escalation, tempdb contention and memory grants are checked next, because they cause the same slowness from a different place.
• 5. Indexes and statistics last — Missing-index suggestions are hints, not a design. Indexes and statistics maintenance are changed where the evidence points, not on a calendar.
• 6. Hardware last — Adding cores or memory is the final answer, not the first, and on a core-licensed edition it is also a licensing event.

Always On on Standard Edition: what a basic availability group does to the design

Microsoft's documentation describes basic availability groups as the Standard Edition version of Always On, and lists their limits. Each limit changes a design decision, which is why edition is the first question in an availability group review.

Enterprise Edition availability groups are the fuller feature set, and an edition change is a licensing decision that belongs to you and your reseller. We design for the edition you hold, and tell you plainly when the requirement needs a different one.

Upgrading off SQL Server 2016 and 2017: the dates and the routes

The dates set the urgency and Microsoft's upgrade documentation sets the routes. SQL Server 2025's documentation lists in-place upgrade from SQL Server 2014 SP3 or later, 2016 SP3 or later, 2017, 2019 and 2022, so most estates have a direct path.

In-place and side-by-side are different risks, not different speeds. An in-place upgrade reuses the server and has the shortest path, but its rollback is a restore. A side-by-side move to a new instance keeps the old one untouched until the new version has run a full business cycle, and shortens the outage to the cutover itself, at the cost of carrying logins, jobs and certificates across. Microsoft's documentation supports restoring a backup from SQL Server 2008 or later to SQL Server 2025 with the compatibility level unchanged, provided it is 100 or higher, so we can keep the old level for the first cycle and raise it later with Query Store evidence.

Log shipping can carry a side-by-side cutover, with one trap Microsoft documents: once a failover makes the SQL Server 2025 instance primary, the older secondary can no longer receive its changes, so the cutover is one-way. For SQL Server 2016, Microsoft also sells Extended Security Updates, which buy time but are not an upgrade; their price and terms come from Microsoft.

Azure SQL decisions: VM, Managed Instance or SQL Database

Three Azure options carry the name SQL Server, and they are not interchangeable. Microsoft publishes the feature gaps, and an instance that uses a gap feature has already made the decision for you.

Managed Instance is the nearest to a drop-in for an instance full of Agent jobs and cross-database queries, and Azure SQL Database is the destination for applications built around single databases. A VM keeps everything, including the operations work. The decision paper maps your instance's features against this table and names the version, backup and exit consequences of each option.

Migration readiness: what we check before any move

A migration readiness assessment is a sizing document, not a migration. It lists what the application depends on so the cost of moving can be estimated database by database, and so the ones that should stay are named.

• Code surface — Stored procedures, triggers, linked servers, CLR assemblies, Service Broker queues and SQL Server Agent jobs: the items that fail on a different platform.
• Compatibility level — The source database's level decides whether a backup restores to a newer version unchanged; Microsoft documents 100 as the floor for SQL Server 2025.
• Security objects — Logins and their SIDs, Transparent Data Encryption certificates and keys, credentials and proxies, which restore with the database only if someone carries them across.
• Distributed transactions — DTC usage, linked-server transactions and cross-database transactions, which several targets do not support.
• Reporting and ETL — What reads the database: SSRS, SSIS, Power BI and ad hoc connections that will need a new connection string or a new design.

For a move to PostgreSQL the same inventory feeds a conversion estimate. That work, and the destination database, are set out on the migration pages, and AceMQ supports both engines under one contract.

Where SQL Server consulting from AceMQ is not a fit

• Business intelligence tooling — SSIS, SSRS and SSAS consulting is out of scope. We work on the database engine and the instance around it.
• Licensing advice — AceMQ gives no Microsoft licensing advice, resells nothing and sets no Extended Security Updates price. Your reseller or Microsoft does.
• Application code — We tell you which queries and settings to change. Your developers make the change, or we work with them.
• Round-the-clock operations — Consulting ends with a plan. Running the instances is a separate service, at Tier 3 or Tier 4.
• A single healthy instance with a capable DBA — That estate may need only a health check.