Azure AI Search can pull or receive content, enrich documents through skillsets, generate vectors, run full-text and vector retrieval in parallel, merge results through Reciprocal Rank Fusion, apply semantic ranking, preserve filters, and scale query or indexing capacity with replicas and partitions. Those controls do not decide who owns an indexer marked Success while documents failed, a stale high-water mark, an enrichment output mapped to the wrong field, a hybrid query that met latency while missing expected evidence, a managed identity blocked by network policy, vector quota exhaustion, an index schema that requires rebuild, or a region outage with no synchronized secondary service.

Datrick provides an ongoing operating layer for an agreed Azure AI Search estate. Named engineers correlate authoritative sources, data sources, push pipelines, indexers, change tracking, skillsets, enrichment cache, vectorizers, embedding models, index schemas and versions, hybrid and semantic queries, filters, relevance labels, document-level access, identities, private links, replicas, partitions, quotas, logs, metrics, alerts, releases, secondary regions, cloud resources, cost, and business outcomes. Microsoft support remains the escalation path for platform defects. Datrick owns the client-specific diagnosis, containment, validation, communication, change, and prevention accepted in the service boundary.

Do you have Azure AI Search in production but no team accountable for turning source drift, indexer warnings, enrichment failures, missing documents, relevance regressions, throttling, access gaps, schema rebuilds, or regional failure into a verified outcome? Start with one representative search service, index, and consuming RAG workflow.

Define ownership from authoritative source to indexed chunk, retrieved evidence, citation, and business answer

A production path can include source databases and document stores; event or batch pipelines; data source connections; indexers or push APIs; document cracking, chunking and skillsets; enrichment cache; Azure OpenAI or Foundry vectorization; search indexes, analyzers, synonyms, vector profiles and semantic configurations; keyword, vector and hybrid queries; filters and document-level access; an agent or application; answer synthesis and citations; and the target workflow. Name which layers the managed service owns, observes, changes, coordinates, or excludes.

Document subscriptions, resource groups, regions, service tiers, replicas and partitions; data sources, indexers, schedules and high-water marks; skillsets and dependencies; indexes, schemas, aliases and versions; embedding deployments; query patterns, filters and semantic configurations; freshness, relevance, latency and availability SLOs; identities and networks; recovery; support hours; severity; change authority; budget; fallback; and Microsoft escalation.

Operate the complete Azure AI Search production surface

Service areaManaged responsibilityBoundary to define
Sources and ingestionAuthoritative source, data source definitions, push APIs or indexers, schedules, change tracking, stable document keys, update and delete behavior, high-water marks, resets, retries, backfill, and source-to-index reconciliation.Source owner, freshness and deletion SLOs, idempotency, throughput, schedule, reset authority, failed-item tolerance, and exception route.
Enrichment and vectorsDocument cracking, chunking, skillsets, input and output mappings, enrichment cache, custom skills, embedding deployment and version, vectorizer, dimensions, quota, warnings, and failed documents.Content types, chunk contract, skill dependency, model compatibility, enrichment cost, sensitive content, retry, and fallback.
Indexes and retrievalIndex schema and versions, analyzers, synonyms, searchable and filterable fields, vector profiles, HNSW or exhaustive KNN, full-text, vector and hybrid queries, RRF, semantic ranker, filters, scoring, captions, answers, citations, relevance, drift, and regression.Expected evidence, query cohorts, relevance and latency SLOs, filter semantics, semantic-ranker budget, reviewer, and business consequence.
Security and networkingMicrosoft Entra roles, managed identities, API keys, document-level access, private endpoints, shared private links, firewalls, Key Vault and customer-managed keys, secrets, logs, and audit.Least privilege, user versus service identity, source and query access, network path, key rotation, audit ownership, compliance, and incident route.
Capacity and observabilityTier, replicas, partitions, search units, storage and vector quota, QPS, latency, throttled queries, indexer documents and skill invocations, dependency health, diagnostic logs, Resource Health, Service Health, alerts, and incident evidence.Traffic and growth profile, SLA topology, headroom, scale authority, metric retention, alert ownership, performance target, and budget.
Reliability and recoveryAvailability-zone eligibility, transient retry, primary-replica behavior, multi-region services, source synchronization, request routing, index and object export, rebuild, recovery exercise, RTO, and RPO.Regional strategy, synchronization owner, write-loss tolerance, failover trigger, source availability, restore acceptance, and Microsoft escalation.
Release, cost, and valueInfrastructure, data sources, skillsets, indexes, aliases, vectorizers, semantic configurations, query and application versions, tests, rollout, rollback, replicas, partitions, enrichment, semantic ranker, model usage, storage, transfer, and anomaly.Source of truth, environments, preview acceptance, approval, compatibility, budget, forecast, unit economics, canary, and acceptance evidence.

Treat freshness, relevance, capacity, schema lifecycle, and regional resilience as one design

Hybrid search runs full-text and vector retrieval in parallel and merges ranked lists through Reciprocal Rank Fusion. Semantic ranker can rerank the candidate set and add captions or answers. The combination often improves relevance, but query text, vector fields, k, filters, analyzers, semantic configuration, source language, chunking, and reranking inputs still need labelled evaluation. A lower latency or higher semantic score is not proof that the retrieved evidence supports the downstream answer.

An indexer has its own status and each execution has a separate result. A run can be marked Success while individual documents failed below the configured tolerance. Track processed, succeeded and failed documents, warnings, execution duration, source counts, deletion behavior, change-tracking state and sampled content. A reset clears the internal high-water mark and requires a later run; it cannot be undone, and reset plus rerun does not automatically remove orphaned documents when source rows disappeared outside supported deletion tracking.

Replicas and partitions solve different constraints. Replicas improve availability and query throughput; partitions increase storage and indexing capacity, including vector quota. Microsoft requires two replicas for the read-only SLA and three for read-write workloads. Vector HNSW structures consume service-level memory quota per partition, while total index storage includes additional physical structures. Capacity changes therefore need query, indexing, enrichment and cost tests rather than one utilization threshold.

Azure AI Search is a single-region service. Multiple replicas can improve intra-region resilience, but regional recovery requires separately configured services, synchronized content and application-level routing. AI Search is not the primary data store and has no self-service backup and restore for a deleted index. Keep rebuildable source truth, export definitions and documents where justified, test a secondary service, and prove relevance and access after recovery.

Distinguish ingestion, enrichment, relevance, security, capacity, recovery, release, and cost failures

SymptomEvidence to reconcileSafe containmentPermanent control
Indexer reports Success but expected documents are missing or staleSource count and timestamps, document keys, indexer execution and failed-item tolerance, warnings and document errors, high-water mark, reset history, mappings, deletion tracking, index count, sampled content, and application cache.Pause dependent automation, preserve execution evidence, lower tolerated errors where safe, run a controlled document or full reprocess, use source fallback, and disclose freshness risk.Source-to-index reconciliation, zero-tolerance classes, failed-document queue, freshness SLO, deletion test, reset runbook, sampling, and alerting.
Skillset, chunking, or vectorization silently drops useful contentInput document, extraction output, skill inputs and outputs, field mappings, warnings, debug session, chunk boundaries, language, embedding model and dimensions, custom-skill dependency, enrichment cache, and target fields.Stop affected ingestion, isolate the content cohort, restore accepted skillset and mappings, bypass unsafe enrichment where possible, and rebuild only after sample validation.Representative document suite, debug-session workflow, mapping contract, chunk-quality checks, model-version gate, dependency SLO, cache policy, and release test.
Hybrid, vector, or semantic relevance regressesLabelled query and expected evidence, keyword and vector candidates, RRF result, k, filters and filter mode, semantic configuration, analyzer, synonyms, scores, captions, source freshness, embedding version, and release.Restore the accepted query, index, vectorizer or semantic configuration, narrow affected cohorts, increase human review, and block consequential answer automation.Query-cohort evaluation, recall and ranking thresholds, grounded-answer tests, filter negatives, semantic budget, canary, drift monitoring, and rollback.
Managed identity, RBAC, firewall, or private-link path failsCaller and search-service identities, role assignments, API or SDK authentication, data source connection, private endpoint and DNS, shared private-link approval, firewall, Key Vault, resource logs, and recent change.Revoke unsafe access, stop public fallback, restore the accepted private route and identity, use a time-bound approved break-glass path, preserve audit evidence, and notify the owner.End-to-end identity matrix, least-privilege tests, denied-user negatives, private DNS checks, approval inventory, credential rotation, and access-change canary.
Queries throttle or latency rises during indexing or enrichmentQPS, search latency, throttled queries, replicas, partitions, search units, storage and vector quota, indexer schedule, skill invocations, dependency latency, request mix, filters, semantic ranker, and recent scale.Throttle or postpone noncritical indexing, reduce expensive query paths, protect critical traffic, scale through approved limits, preserve evidence, and communicate degraded capacity.Workload-isolated load test, SLA topology, headroom policy, index schedule, QPS and throttle alerts, vector quota forecast, scale runbook, and cost guardrail.
Schema release, deleted index, regional outage, or cost control failsInfrastructure and object definitions, source availability, current and candidate indexes, aliases or app configuration, document counts, relevance and access tests, secondary service synchronization, routing, replicas, partitions, model and semantic usage, and recent change.Stop cutover, preserve the current index, route to an accepted service or source fallback, rebuild in isolation, cap noncritical consumption, and communicate RTO, RPO, quality, or budget risk.Versioned definitions, side-by-side index, recovery corpus, multi-region synchronization, failover exercise, post-recovery evaluation, alias or config rollback, cost attribution, and alerts.

A retry is not automatically safe. Before rerunning an indexer, resetting its change-tracking state, replaying push ingestion, rebuilding enrichment, deleting documents, switching an alias, scaling a service, or failing over regions, determine what already committed, which documents succeeded or failed, whether orphaned content remains, whether cached enrichments are valid, whether the candidate index preserves access and relevance, and whether the application already exposed a response. Reconcile source, document, enrichment, index, query, region, application, and business state before reopening traffic.

Release sources, skillsets, indexes, query behavior, capacity, security, and applications together

A production Azure AI Search release includes source and document contracts, data sources, indexers and schedules, skillsets and dependencies, embedding model and dimensions, index schemas and versions, analyzers and synonyms, vector profiles, semantic configurations, filters and access logic, managed identities and network controls, replicas and partitions, application queries, evaluation sets, monitoring, recovery, budgets, rollout, and rollback. A valid object update can still change freshness, relevance, latency, access, availability, and cost.

Many field attributes require an index rebuild. Create a versioned index beside production, load representative content, reconcile counts, inspect failed documents, test keyword, vector, hybrid and semantic relevance, run access negatives, load realistic query and indexing concurrency, verify vector quota, simulate dependency and region failure, prove recovery, canary the application and index change together, then switch through an index alias or controlled application configuration. Index aliases remain preview, so preserve the previous index and an explicit rollback route.

Onboard through inventory, baselines, controlled failures, and shadow operations

  1. Inventory: subscriptions, resource groups, regions, tiers, replicas, partitions, services, data sources, indexers, skillsets, indexes, aliases, vectorizers, semantic configurations, queries, applications, identities, networks, alerts, secondary services, and outcomes.
  2. Responsibility: define supported layers, document and index freshness, relevance, latency and availability SLOs, severity, access, change authority, budget, dependencies, fallback, Microsoft escalation, and exclusions.
  3. Baseline: measure source and index counts, failed documents and warnings, indexing duration, chunk and vector quality, query-cohort relevance and latency, QPS, throttling, vector and storage quota, access, replicas, partitions, recovery state, cost, and incidents.
  4. Controls: validate stable keys, deletion, mappings, skillsets, embedding compatibility, index and query configurations, least privilege, private connectivity, capacity alerts, relevance evaluation, rebuild and recovery, releases, rollback, attribution, and alerts.
  5. Exercise: rehearse missing documents, indexer reset, skill failure, embedding mismatch, relevance regression, access denial and exposure, query throttling, vector quota pressure, schema rebuild, regional failure, credential rotation, and model dependency outage.
  6. Transition: operate in shadow, close or accept material gaps, publish runbooks and escalation routes, and accept the steady-state support scope.

Start with the Azure AI Search index that already influences customer, financial, operational, compliance, or workforce decisions. Datrick can define the operating boundary, close material control gaps, and transition one representative search and RAG workload into managed support.

Request an Azure AI Search operations review

Official references and adjacent operating guides

Frequently asked questions

What is included in Azure AI Search production support?

A defined service can include data sources, push ingestion and indexers, skillsets and enrichment, index schemas, vectorizers and embeddings, hybrid search, semantic ranker, filters, relevance evaluation, managed identity and private connectivity, monitoring, replicas and partitions, incidents, blue-green releases, multi-region recovery, cost, runbooks, and reporting.

How many Azure AI Search replicas are needed for production?

Microsoft recommends a billable tier with at least two replicas for production resilience. The Azure AI Search SLA requires at least two replicas for read-only query workloads and at least three replicas for read-write workloads that include indexing. Capacity still needs load testing because replicas improve query throughput while partitions primarily increase storage and indexing capacity.

Can an Azure AI Search indexer succeed with document errors?

Yes. An indexer run can report Success when individual documents failed if the failures remain below the configured maximum failed items. Monitor processed and failed counts, warnings, document-level errors, source-to-index reconciliation, and freshness instead of treating the top-level status as proof that the corpus is complete.

How should Azure AI Search indexes be released without downtime?

Many index field attributes cannot be changed without a rebuild. For production schema changes, create a versioned index beside the current index, load representative content, test relevance, security, freshness, capacity, and failure behavior, then switch the application through an index alias or controlled configuration change. Index aliases are currently a preview capability, so maintain an explicit rollback path.

How long does Azure AI Search managed support onboarding take?

A focused onboarding commonly takes two to four weeks for a representative production service. It covers sources, indexers, skillsets, indexes, vectors, query and relevance baselines, identities, networks, capacity, monitoring, incidents, releases, recovery, controlled failure exercises, runbooks, and acceptance of the steady-state operating scope.

Comparing managed and distributed enterprise search operations?

Review the Elasticsearch vector search production support boundary