06 — Azure Glossary (for the CARR / BW team)

Plain-English definitions of the Azure terms that come up in CARR's migration, each tied back to the Supabase concept it replaces where relevant. Keep this the friendly on-ramp.
Triggers: "what is", "azure term", "glossary", "what does X mean".

Data + backend

⚠ 2026-06-17 client decision: BW IT locked Azure SQL as the database target (not Postgres). The Postgres-Flexible-Server entries below are kept for context but are no longer the plan — see 07_azure_sql_conversion.md.

• Azure SQL (the target) — Microsoft's managed SQL Server family, using the T-SQL dialect. CARR is migrating here per BW standard. Comes in three flavors (below). Replaces: Supabase Postgres — via a full code conversion, not a lift-and-shift.
• T-SQL (Transact-SQL) — SQL Server's SQL dialect. Different from Postgres's SQL + PL/pgSQL: every CARR function, view, trigger, and RLS policy must be rewritten into it.
• Azure SQL Managed Instance (MI) — the PaaS flavor closest to a full SQL Server (has SQL Server Agent, cross-database queries). BC's recommended target — easiest landing for CARR's 21 scheduled jobs + procedural code.
• Azure SQL Database — the single-database PaaS flavor. Cheaper, but no SQL Agent (uses Elastic Jobs) and more constraints.
• SQL Server on a VM — full SQL Server you run/patch yourself (IaaS). Most control; defeats BW's managed-cloud preference.
• Azure Database for PostgreSQL (Flexible Server) — Microsoft's managed PostgreSQL (same engine as Supabase). Was BC's recommended target; superseded by the 6/17 Azure SQL decision.
• Row-Level Security (RLS) — rules limiting which rows a user can see/edit (a rep sees only their leads). CARR has 252 such policies. In Azure SQL this is rebuilt as a SECURITY POLICY + predicate function (below), not Postgres CREATE POLICY.
• SECURITY POLICY (Azure SQL) — the T-SQL object that attaches FILTER (read) and BLOCK (write) predicates to a table to enforce RLS. The Azure SQL replacement for Postgres RLS policies.
• SESSION_CONTEXT — a per-connection key/value store in Azure SQL the app sets (sp_set_session_context) so RLS predicates know who the user is. Replaces Postgres auth.uid() as the identity source inside the database.
• OPENJSON / JSON_VALUE / JSON_QUERY — T-SQL functions for reading JSON held in NVARCHAR(MAX). How CARR's 80 JSONB columns are queried after conversion (Azure SQL has no binary JSONB type).
• pg_cron — a Postgres extension that runs scheduled jobs inside the database. CARR has 21. No in-database equivalent in Azure SQL → moves to SQL Agent (MI) or Elastic Jobs (SQL Database).
• pg_net / http — Postgres extensions that let the database make HTTP calls. No Azure SQL equivalent → that logic moves out to Azure Functions.
• Azure Key Vault — secure store for secrets (API keys, passwords). Replaces: Supabase Vault.
• Azure Blob Storage — file/object storage (docs, images). Replaces: Supabase Storage.
• Azure Event Grid / SignalR — event fan-out / live updates. Replaces: Supabase Realtime.

Compute + hosting

• Virtual Machine (VM) — a full rented computer in the cloud you manage yourself. Most control, most upkeep.
• Azure Kubernetes Service (AKS) — managed Kubernetes for running many containers at scale. Powerful, complex.
• Azure Container Apps — run containers without managing Kubernetes. Good middle ground for apps/services like CARR's Edge Functions.
• Azure App Service — managed hosting for web apps/APIs; "deploy your code, Azure runs it."
• Azure Static Web Apps — hosting purpose-built for single-page frontends (React) + a serverless API. Candidate host for CARR's Vite/React UI.
• Azure Functions — serverless functions that run on a trigger (HTTP, timer, queue). Candidate replacement for CARR's Deno Edge Functions.
• "Virtual environments" (BW's phrasing) — usually means isolated dev / test / prod environments. In Azure this is done with subscriptions, resource groups, and landing zones (see below).

Identity + governance

• Microsoft Entra ID (formerly Azure Active Directory / Azure AD) — Microsoft's identity system; how BW employees sign in. Replaces: Supabase Auth for all CARR users (all are BW-internal since CARR is a BW subsidiary).
• Microsoft Entra External ID (CIAM) — Entra for external users (customers, partners) who aren't BW employees. Not needed for CARR — all users are BW workforce.
• Managed identity — lets an Azure app authenticate to other Azure services (like Key Vault) without storing a password.
• Resource group — a folder that groups related Azure resources (DB, app, storage) for one project/environment.
• Subscription — a billing + access boundary that contains resource groups.
• Management group — groups multiple subscriptions for org-wide policy (enterprise scaffolding).
• Azure Landing Zone — Microsoft's blueprint for a well-governed enterprise Azure setup (networking, identity, policy, cost controls) before apps move in. BW IT will likely impose one.
• Azure Policy / RBAC — rules (Policy) and role-based permissions (RBAC) that govern what can be deployed and who can do what.

AI

• Microsoft Foundry (formerly Azure AI Foundry) — Azure's platform for building AI apps and agents. Went GA March 2026.
• Foundry Agent Service — the managed service within Foundry for building, deploying, and scaling AI agents. A managed home for an AI-agent layer.
• Model catalog — the menu of AI models (OpenAI, Anthropic, Llama, Phi, etc.) you can deploy in Foundry.
• GA vs preview — GA (General Availability) = production-ready, supported. Preview = early, may change/break, not for production. Always check which one applies — Azure AI features move monthly.

Migration tooling

• SSMA (SQL Server Migration Assistant) — Microsoft's free DB-migration tool. Does NOT support PostgreSQL as a source (only Access, Db2, MySQL, Oracle, SAP ASE) — so it can't convert CARR. Named here because people assume it can.
• Azure Database Migration Service (DMS) — Azure's managed migration service. Does not convert Postgres → Azure SQL; not applicable to CARR's path.
• Azure Data Factory (ADF) — Azure's data-pipeline service; a candidate for bulk-loading CARR's data (PG source → Azure SQL sink) once the schema exists.
• bcp / BULK INSERT — SQL Server's bulk data-load utilities; a scripted alternative for moving CARR's ~500 MB of data in.
• Ispirer / DBConvert — commercial tools that automate part of a PostgreSQL → Azure SQL move (schema + data + some code); leave the procedural/RLS tail manual.
• LLM-assisted SQL conversion — using a large language model (with human review) to convert the procedural + RLS + Supabase-specific SQL tail that commercial tools don't handle.

DevOps

• GitHub Enterprise — the enterprise tier of GitHub BW uses; CARR's repo is migrating into it.
• GitHub Actions — GitHub's CI/CD automation; can deploy straight to Azure.
• OIDC federated credentials — a passwordless, modern way for GitHub Actions to authenticate to Azure (preferred over storing secrets).
• Azure DevOps — Microsoft's alternative CI/CD suite (Pipelines, Boards). An enterprise picks GitHub Actions or Azure DevOps.
• Dataverse — Microsoft's structured data backend for Power Platform. Relevant because BW floated Power Apps + Dataverse as a frontend alternative to the existing React SPA (note: Lovable is just hosting — the comparison is to the React app itself, not to Lovable).
• Power Apps / Power Automate / Logic Apps — Microsoft's low-code app + workflow tools BW proposed for some Edge-Function / UX needs.