Microsoft’s Azure AI Language Retirements Push NLP Workloads Toward Model Portability

What changed

Microsoft is preparing to retire several Azure AI Language capabilities in Foundry Tools, shifting customers away from fixed-purpose natural language APIs and toward model-based implementations in Microsoft Foundry. The affected features include Key Phrase Extraction, Entity Linking, Sentiment Analysis and Opinion Mining, document and conversation Summarization, Conversational Language Understanding, Custom Question Answering, Orchestration Workflow, and Custom Text Classification.

The retirement window is long, but it is not theoretical. Most of the listed features are scheduled to be retired by March 2029, while Entity Linking has an earlier retirement date of September 20, 2028. Microsoft’s guidance is to rebuild these patterns using Foundry-hosted models, retrieval, fine-tuning, and agent workflows rather than waiting for one-for-one API replacements.

That matters because the old Azure AI Language model was operationally simple. A developer called a specialized endpoint for sentiment, key phrases, entity linking, or custom intent classification, then received a predictable JSON response. The new model asks architects to compose the same behavior from foundation models, prompts, retrieval indexes, model deployments, and output validation. In exchange, teams get broader model choice, longer context windows, better customization paths, and a single inference pattern across OpenAI, Microsoft, Mistral, Anthropic, Cohere, Phi, and other catalog models.

The technical center of gravity is the Foundry chat completions path. Microsoft’s examples point developers toward a unified endpoint pattern such as https://<your-resource>.services.ai.azure.com/openai/deployments/<your-deployment>/chat/completions?api-version=2024-10-21, with API key authentication or Microsoft Entra ID authentication depending on the deployment model. That is a strategic detail, not just an implementation detail. It means language features that used to be separate product APIs are being normalized into model calls that look more like Azure OpenAI style inference.

For enterprises, this is less a feature removal than a product boundary change. Microsoft is moving common NLP capabilities from service-owned logic into customer-owned AI application design. The old service decided how sentiment, entity linking, intent classification, and summarization worked. The new architecture gives the customer more control, but also more responsibility for schema design, test sets, cost controls, hallucination handling, and model lifecycle management.

Provider comparison

Azure’s direction fits a wider cloud pattern. The major cloud providers are all trying to make foundation models the common abstraction for AI workloads, but they are taking different routes.

Microsoft Foundry is strongest for organizations already invested in Azure, Microsoft identity, Azure AI Search, Azure OpenAI, Microsoft governance tooling, and enterprise agent development. Its advantage is not just model access. It is the combination of model catalog, deployment management, Foundry Agent Service, Azure AI Search retrieval, Entra ID, observability, and Microsoft’s enterprise compliance posture. For companies already running Azure AI Language, Foundry is the most natural migration target because data, access controls, network design, and procurement are likely already aligned.

AWS Bedrock has a similar multi-model message, with access to Amazon and third-party models through managed APIs. Bedrock will appeal to teams standardized on AWS IAM, VPC patterns, CloudWatch, Lambda, Step Functions, OpenSearch, and Amazon Q integrations. For a company already running its knowledge base in S3 and OpenSearch, rebuilding Custom Question Answering as a Bedrock retrieval workflow may be as natural as using Azure AI Search on Microsoft’s side.

Google Vertex AI is a strong comparison point for teams invested in Gemini, BigQuery, Document AI, and Google’s ML tooling. Vertex AI’s strength is its data and ML platform integration. If the enterprise NLP workload sits close to analytics, data science, or BigQuery-governed datasets, Vertex AI can be attractive for classification, summarization, and retrieval-augmented generation.

The most important strategic difference is how much the replacement should remain Azure-specific. If the goal is minimum disruption from Azure AI Language, Foundry is the practical path. If the goal is model portability, the architecture should treat Foundry as one provider implementation behind an internal AI gateway. That gateway can normalize prompts, model selection, logging, retries, JSON schema validation, and cost attribution across Azure, AWS, and Google.

The retired features also map to different model strategies. Key Phrase Extraction and Sentiment Analysis can often move to smaller, cheaper models such as Phi or Mistral because the task is bounded and easy to evaluate. Summarization and conversation analysis may justify larger context models such as Claude, GPT-4o, or Microsoft’s first-party MAI models where available. Custom Question Answering should not be treated as a simple model prompt. It needs retrieval, ranking, source grounding, and answer policy controls. Custom Text Classification and CLU replacements should be decided based on taxonomy complexity. A small number of stable labels can work well with prompting. Large intent catalogs, regulated workflows, or high-volume support routing usually justify fine-tuning.

Pricing is where many migrations will become more complex. Azure AI Language pricing has traditionally been feature and transaction oriented, with published pricing for Azure Language in Foundry Tools. Foundry model pricing is more variable because the cost depends on the selected model, input tokens, output tokens, context length, provisioned throughput choices, retrieval infrastructure, embeddings, reranking, and evaluation workloads. A summarization job that was previously one API call may become embedding storage plus search plus model inference plus logging.

That does not automatically mean higher cost. Some workloads will become cheaper if they move from specialized APIs to small open or Microsoft-hosted models. Others will become more expensive if every short classification task is sent to a frontier model with a large context window. The right pricing comparison is not service versus service. It is task class versus task class. Use small models for extraction and classification, larger models for ambiguous reasoning, rerankers for deterministic answer selection, and retrieval to avoid paying a large model to read irrelevant context.

Business impact

The business impact is that NLP workloads now need portfolio management. Enterprises should inventory every Azure AI Language dependency, classify it by feature, volume, latency target, data sensitivity, and user-facing risk, then choose a migration pattern for each one. A support chatbot using CLU and CQA has a different risk profile than an internal analytics job extracting key phrases from documents once a day.

For Key Phrase Extraction, Sentiment Analysis, and basic text classification, the migration can be relatively contained. Teams can create prompts that return the same JSON schema as the old API, add schema validation, and run regression tests against historical inputs. The main work is evaluation. The old API was consistent because the service owned the behavior. A generative model may vary unless temperature, instructions, schema enforcement, and fallback handling are carefully controlled.

Entity Linking needs more design attention. Named entity recognition alone is not the same as linking entities to canonical IDs. If the old workflow depended on linked Wikipedia-style references or enterprise master data, the replacement should combine extraction with retrieval against an approved knowledge base. Azure AI Search vector search is a natural Azure component for that pattern. In a multi-cloud architecture, the equivalent might be OpenSearch on AWS or Vertex AI Search on Google Cloud.

Summarization migrations should be used to revisit information governance. Long-context models make it easier to summarize full documents and conversations, but they also increase the amount of sensitive data sent to inference endpoints. Teams should define which documents can be summarized, whether summaries need citations, how long prompts and outputs are retained, and whether high-risk content requires redaction before inference.

CLU and Orchestration Workflow retirements are the most architectural. These features often sit directly in user-facing bots and workflow routers. Replacing them with a general model can improve flexibility, but it can also blur business rules. A strong migration keeps intent schemas explicit, requires structured JSON outputs, validates every action before execution, and separates intent detection from irreversible operations. For example, a model can classify CancelBooking, but application code should still enforce identity checks, policy checks, and confirmation steps.

Custom Question Answering is likely to become a RAG modernization project. The safest path is to preserve deterministic answer behavior first: export existing question-answer pairs, index them, retrieve candidates, rerank them, and return the stored answer when confidence is high. Generative answers can be added later for cases where synthesis is valuable. That staged approach reduces migration risk and gives business owners a clean comparison between the old answer and the new answer.

The strategic advice is to avoid a single replacement model decision. This is a chance to build an AI workload routing layer. A cloud consultant would treat these retirements as a prompt to standardize six things across the enterprise: model inventory, prompt templates, JSON schemas, evaluation datasets, cost telemetry, and fallback policy. Once those controls exist, teams can compare Foundry models against AWS Bedrock or Google Vertex AI models without rewriting every application.

For Azure-centered organizations, the near-term recommendation is clear: start with Foundry because it is the lowest-friction migration path from Azure AI Language. Keep the old API response contracts where possible, use Foundry models behind adapters, and test every replacement against historical production traffic. For multi-cloud organizations, build the adapter layer first, then decide which workloads must stay on Azure and which can be portable.

The March 2029 deadline gives enterprises time, but not enough time to treat this as a documentation update. The migration touches application contracts, cost models, data governance, quality testing, and vendor strategy. The companies that handle it well will not simply replace eight APIs. They will leave with a more flexible NLP platform that can route work to the right provider, the right model, and the right price point for each business task.