By Kevin Harmer, Chief AI & Data Officer, ArchitectNow
A recap of the half-day workshop we ran with Microsoft at the Microsoft Innovation Hub in Irvine, California, on 10-22-26.
If your AI reads data that wasn't organized for it, your leaders get confident wrong answers. At our Irvine workshop with Microsoft, I showed how we fix that, from SQL Server through Azure SQL and Microsoft Fabric to Foundry agents that answer from the numbers and the documents together.
An insurance company I worked with recently asked its AI a board-level question: should we keep pursuing business in New Mexico, or exit the region?
Answering it takes structured data, like claims, profitability and the rate increase needed to hit targets, plus unstructured knowledge, like whether courts are trending toward larger judgments on contested claims. Their first version loaded PDF reports and downloaded articles into a Copilot agent, and it recommended exiting.
Before the CEO took that to the board, she challenged it. She found the wrong calculations, run on the wrong numbers, and documents the agent had only partly read before it guessed. Pointing the agent straight at their SQL database didn't fix it either, because nothing described that data in business terms.
So we mirrored the SQL data into Microsoft Fabric, built a semantic model and an ontology on it, and gave a Foundry agent two sources: Fabric IQ for the numbers and an Azure AI Search index of the documents. Same question, new answer: stay in New Mexico, and set rates at a level that's profitable and still sells policies.
That story opened the workshop. Here's the rest of the morning.
Why the database decision is now an AI decision
A lot of teams owe a SQL Server decision anyway. SQL Server 2016 reached the end of extended support on 07-14-26, SQL Server 2017 follows on 10-12-27, and Extended Security Updates turn security patches into a line item.
AI raises the stakes, starting with load. I had a customer whose operational data platform carried SLA commitments to 1,000 of their own customers. People inside the company started asking it tough questions through AI, those questions ate all of its capacity for hours, and all 1,000 customers had an outage. A separate, current copy of the data has always been good practice for BI, and with AI it becomes essential.
Identity matters just as much. An agent should see only what the person asking is allowed to see. On premises, that hop often runs through a shared service account, and if you're not careful, that's how an agent hands someone executive salaries. In Azure, the signed-in user's identity carries through to the data.
The database you choose this year decides what your agents can see next year.
Size it from what the workload actually does
Before picking a target, run an assessment. We use the Azure Migrate appliance, which discovers your SQL Servers without installing anything on them, or Azure Arc. Either one watches the real workload for a couple of weeks, then gives you each server's readiness, its blockers, a right-sized target at the 95th percentile of the load it actually saw, and a monthly cost. Copying your on-premises server size into the cloud is how people overpay, and if the load changes later, resizing in Azure is a flick of a switch.
Then pick the target per workload:
| Target | Pick it when |
|---|---|
| Azure SQL Database | It's a new cloud app, or the load spikes and then sits idle. Serverless bills per second and can pause. |
| Azure SQL Managed Instance | You're moving a SQL Server that relies on SQL Agent jobs, cross-database queries or linked servers. |
| SQL Server on an Azure VM | You need the operating system itself. It's my third choice. |
Our demo company, Chouteau Landing Brewing (a fictional St. Louis brewer), came back as Managed Instance, General Purpose, four vCores. Its data would have fit Azure SQL Database. The SQL Agent jobs decided it.
On cost: every so often I hear a horror story about someone whose bill doubled in Azure SQL. That's what happens when a move isn't set up deliberately. Set up the right way, we consistently see costs go down, and Azure Hybrid Benefit carries over the licenses you already own: one SQL Server Enterprise core with Software Assurance covers four General Purpose vCores.
Move with minutes of downtime
For Chouteau, I wanted a copy in Azure that stays current while the old server keeps running, and I wanted to read it, so the team could compare reports side by side before committing. Managed Instance link does both. (The Log Replay Service copy can't be read until cutover.)
It's built on availability groups, which SQL Server teams already know. The managed instance joins as a replica, the database seeds, and changes replicate in near real time. In the demo, I added a new customer complaint on the on-premises server and queried the managed instance. It replicated faster than it took me to describe.
Cutover is the nice part. The copy is already current, so there's no big restore at midnight on a Saturday. In a five-minute window you stop writes, make the managed instance the primary, and point the apps at it.
Mirror it into Fabric and retire the pipelines
Once the data lives in Azure SQL, the next move is Fabric mirroring. You pick the tables once, Fabric takes a snapshot, and changes stream into OneLake in near real time, in open Delta format, with a SQL endpoint ready to query. Setup takes a few minutes, and there's no pipeline to build, schedule or repair. (Every organization I talk to is tired of ETL and tired of pipelines.) The replication compute is free, and each Fabric capacity unit includes a free terabyte of mirroring storage, so an F32 capacity covers 32 terabytes.
That retires two line items a lot of SQL shops carry: the readable secondary licensed only to keep reporting off the primary, and the nightly ETL that lands yesterday's data in a lake.
Plan for two things. Row-level security, masking, permissions and sensitivity labels set in SQL don't carry over to the mirror, so set them once in OneLake security and Purview, and every report and agent downstream inherits them. And tables with json columns, Always Encrypted, or temporal or ledger history don't mirror, so design around them.
Give the agent business meaning
This is the step the insurer was missing. Mirrored tables are still raw tables, and an agent reading them can still serve up the wrong numbers. Fabric IQ is the layer that tells an agent what the data means.
I started with a graph on the brewery's data, which reads as topics and relationships: an ingredient is supplied by a supplier, a batch is fermented in a tank, and so on. Starting from the complaints about gushing beer, one graph query walked back to the malt lot they shared, which in SQL is a pile of multi-join queries. Then I walked it forward to every key account that got beer brewed with that lot, complaint or not. I think that's the clearest way to see the difference between joining tables and navigating relationships, which is how agents work.
Next, the data agent, which turns a plain-English question into a query. I asked two agents on the same data: what was our revenue this year? The raw one had no instructions. It read "this year" as the calendar year and said $4.8 million. The trained one knew the company, its data sources and its business rules, including when the fiscal year starts, and said $6.1 million, which is right. On a follow-up by fiscal year, it chose the Power BI semantic model over the raw tables, since semantic models handle time-based questions far better than SQL.
The ontology, in preview, holds rules. One I wrote: when an ingredient lot is quarantined, every batch, package and delivery that came from it is at-risk product to withdraw, so an agent that asks what to do finds the answer there. It does behave like a preview. Microsoft revamped the service a couple of weeks before the workshop and broke the preview ontologies I'd built, the morning I was about to demo one at a conference. (That was fun.)
I want to know about the risk brewing right now, along with the risk already shipped, so I set up an operations agent, also in preview, to watch simulated tank telemetry. Its instructions were plain English: treat a tank running two degrees hot as critical, alert the brew house team in Microsoft Teams, and when they say yes, run a notebook that holds the batch. It caught the deviation during the demo and sent the alert.
Put the numbers and the documents in one answer
In a recall, you need the affected accounts from the numbers and the required steps from the documents. So in Microsoft Foundry I set up an incident advisor with two sources: the business facts through Fabric IQ, and the brewery's policies, procedures and contracts through Foundry IQ.
I asked it one question: which key accounts received product brewed with this malt, and what does our withdrawal procedure require? Fabric IQ can answer the first half on its own. The second half lives in the documents, and Foundry brought both into one answer. It's the same pattern that turned the insurer's answer around.
Where to start
Sequence the work: lay the foundation, move two or three low-risk databases to learn on, bring the core systems over with Managed Instance link, then mirror, model and add your first agent. I wouldn't start with your biggest system.
If you want to know where your own SQL estate stands, start with our SQL Migration Assessment. It's the assessment from the workshop, run on your estate: every database inventoried, a readiness verdict and right-sized target for each, monthly cost with your licenses applied, and a recommended first wave. It's free. To book it, email Craig Brandt at cbrandt@architectnow.net.
If you'd rather plan the whole path first, our Data Strategy Day is one complimentary working day with your business and IT leaders. You leave with a data platform design and a high-level roadmap built around the BI and AI outcomes that come first for you.