Why do AI projects stall on data and infrastructure, and what has to be fixed first?
Because a model can only be as good as what it retrieves, and most companies discover mid-project that their customer records live in four systems that disagree. We fix the layer underneath: SQL Server performance, Azure architecture and cost, and the data quality work that decides whether anything built on top of it works. Often this is the highest-return engagement we sell, because it is measurable in dollars in the first month.
- Read the workloadtwo weeksCapture what actually runs and rank by total time consumed, not by the queries people complain about.
- Index before rewritingMost of the first wins are indexing. They are also the least disruptive to ship.
- Rewrite before re-architectingA handful of queries usually account for most of the time. Fix those before redesigning anything.
- Re-architect before buying hardwareBigger instances are the most expensive way to hide a query problem, and the easiest to justify by accident.
- Then the data itselfWhat is duplicated, what disagrees across systems, and which of those actually blocks the work you want to do.
Each step is measured against the baseline, so the improvement is a number rather than an impression.
Cloud, Data & Platform
The project that stalls in month four
It starts well. A use case is chosen, a model is selected, a prototype answers questions correctly in a demo. Then it meets production data and starts giving confident wrong answers, because the customer table has three records for the same company, the product catalogue has fields nobody has populated since 2019, and two systems disagree about which orders shipped.
Nobody wrote that down as a risk, because everyone who knew it had stopped noticing.
This service area exists to find it in week two rather than month four.
What we actually do
Read the workload. For SQL Server, we capture what actually runs over a representative period and rank by total time consumed rather than by the queries people complain about. The slowest single query is rarely the problem. The one that runs fifty thousand times an hour and takes 80ms usually is.
Fix in the cheap order. Indexing before rewriting, rewriting before re-architecting, re-architecting before buying bigger hardware. Each step gets measured against the baseline, so the improvement is a number rather than an impression.
Look at Azure honestly. Architecture review and cost review together, because they are the same conversation. Most of the savings we find are structural: capacity sized for a peak that stopped happening two years ago, storage that was never re-tiered, non-production environments running at production scale around the clock.
Assess the data itself. What is duplicated, what disagrees across systems, what is missing, and which of those actually blocks the work you want to do. Not every data problem is worth fixing. The remediation plan sequences them by what unblocks the most downstream value.
Why this pairs with modernization
The database and the application that sits on it accumulate debt together, and usually the same support dates force both. SQL Server 2016 left extended support in July 2026; the applications querying it are frequently on framework versions in the same condition.
When both are true, this service area and Legacy Code Modernization run as one engagement, with the data work slightly ahead so the application migration has something stable to move onto.
The argument for doing this first
This is the least fashionable thing we sell and frequently the most valuable. A query tuning engagement that takes four weeks and removes a recurring cost is measurable immediately, needs no organizational change, and buys the credibility to do the harder work afterwards.
If you are looking for one place to start where the result is unambiguous, this is usually it.
What you get
- Query and index tuning against your actual workload, measured before and after
- A read of where the time goes: the queries, the blocking, the missing indexes, and the ones that should be dropped
- Cloud architecture and cost review on Azure, AWS, or GCP, with savings ranked by effort to capture
- Cloud development: the services, storage, networking, and identity a workload actually needs, built rather than diagrammed
- A data-quality assessment: what is duplicated, what disagrees between systems, and what is missing
- A remediation plan that sequences the fixes by what unblocks the most downstream work
- Platform modernization roadmap, where versions are out of support or heading there
- Capacity and cost baselines so the improvement is visible to whoever approved the spend
Questions we get
- Is this really an AI service?
- It is the one that decides whether the others work. Nobody's AI works on bad data, and about half the assessments we run end with data repair as the first recommendation rather than a model. We would rather tell you that in week three than in month six.
- Our SQL Server is slow but nobody knows why. Where do you start?
- The workload, not the schema. We capture what actually runs, rank by total time consumed rather than by individual duration, and usually find that a handful of queries account for most of it. That list is the plan, and the first fixes are typically indexing rather than rewriting.
- Can this reduce our Azure bill?
- Usually, and the savings are often structural rather than clever: resources provisioned for a peak that no longer happens, storage tiers that were never revisited, and development environments running at production scale overnight. We rank findings by effort to capture, so the easy money comes first.
- We are still on SQL Server 2016. How urgent is that?
- It left extended support in July 2026, so you are running an unpatched database engine. The upgrade itself is usually the easy part. The schema and query debt underneath it is where the work is, and it is normally the first time anyone has looked in a decade.
- Do you work on databases other than SQL Server?
- PostgreSQL and the managed cloud databases, yes. The deepest experience is SQL Server and Azure, and we will say so rather than learn on your system.
How it starts
Two-week assessment, then four to eight weeks per workstream. You keep everything produced, whether or not there is a next part.