If your engineering team spends more sprint points maintaining Azure custom speech models than shipping product features, your ASR pipeline is bleeding engineering capacity into infrastructure toil. Microsoft built Azure Speech as one module inside a larger cloud ecosystem, not as dedicated audio infrastructure. That lineage shows in the architecture: batch and streaming live behind different SDK surfaces. Every downstream feature, such as diarization, sentiment, and translation, routes through separate Azure services with separate billing meters. And when real-world audio includes accents or background noise, the base models can degrade to a degree that makes custom training necessary for some use cases.
This guide provides a technical blueprint for moving your production ASR pipeline to Gladia. We map Azure's API structures, deployment paths, and feature set directly to our unified API, and walk through a zero-downtime transition your team can execute in under 24 hours.
Mapping Azure Speech features to Gladia
The tables below show how Azure's ecosystem maps to our single API surface. Use these as a parity checklist before writing a line of migration code.
Table 1a: Core transcription capabilities
| Capability |
Azure Speech |
Gladia |
| Async (batch) transcription |
Batch Transcription API |
POST /v2/pre-recorded |
| Real-time streaming |
Speech SDK (WebSocket) |
WebSocket via session token |
| Speaker diarization |
Included in batch, add-on on real-time ($0.30/hr) |
Included (async only) |
| Sentiment analysis |
Separate Azure Text Analytics |
Included |
| Translation |
Separate Azure Translator |
Included |
| Named entity recognition |
Separate Azure Language service |
Included |
| Custom vocabulary |
Custom Speech training cycle |
API parameter (no retraining) |
Table 1b: Deployment and data handling
| Capability |
Azure Speech |
Gladia |
| On-premises containers |
Supported |
Not available (cloud-only) |
| Data training opt-out |
Controlled via endpoint logging settings. Verify current policy in Microsoft's data privacy documentation |
Default on Growth/Enterprise |
| Authentication header |
Ocp-Apim-Subscription-Key |
x-gladia-key |
| Language support |
140+ locales |
Broad multilingual coverage of more than 100+ languages |
The deployment and data governance differences matter most for compliance-sensitive pipelines.
Tailoring speech models for domain data
Azure's Custom Speech workflow requires uploading training datasets, running fine-tuning jobs, managing model versions, and re-evaluating against held-out test sets. For a team transcribing financial calls or medical audio, that cycle adds real engineering time and GPU cost most teams don't budget for upfront.
We took a different path. Solaria-3 is built for real-world European business audio across English, French, German, Spanish, and Italian, handling noisy recordings and accented speech out of the box without any custom training. For broader multilingual coverage, Solaria-1 supports code-switching and language breadth across the full supported languages list. When domain-specific terminology matters, our custom vocabulary feature accepts a list of terms as a JSON parameter at API call time, with no model retraining and no version management burden.
Azure Speech to Gladia deployment paths
Azure's container offering lets teams pull the speech-to-text runtime into Kubernetes clusters or on-premises hardware, which satisfies air-gapped requirements in regulated environments. We run on dedicated cloud clusters in EU and US regions, which covers GDPR-mandated data residency and eliminates hardware provisioning, patching, and capacity planning from your team's backlog.
If your compliance requirement is data sovereignty, our EU cluster satisfies that boundary by default. If your requirement is strict air-gapping with no external network path for audio data, that is a genuine gap versus Azure containers, and self-hosted options are the right evaluation path for that constraint. Our compliance hub covers how SOC 2 Type II, ISO 27001, HIPAA, and GDPR apply to all other regulated-industry requirements.
Optimizing live transcription flows
Azure's streaming transcription runs through the Speech SDK, which manages WebSocket lifecycle internally. We expose the WebSocket surface directly via a two-step handshake: POST to /v2/live returns a session-scoped token, and you then open a WebSocket connection to wss://api.gladia.io/v2/live?token={token}. The session URL approach means you can hand the connection to a browser client without exposing your API key, and you can resume a dropped session without re-authenticating. Solaria-1 powers real-time streaming with partials under 103ms and final transcript latency around 270ms, which sits inside the budget for voice-agent pipelines.
Handling high-volume async transcription
Azure's batch transcription API accepts a list of content URLs and processes them asynchronously, returning results to a polling URL. Our async pipeline works the same way through POST /v2/pre-recorded, accepting a URL or direct file upload and returning a job ID you can poll or webhook. The practical difference is throughput: we process approximately one hour of audio in under 60 seconds, and the pre-recorded API reference documents the full parameter schema, including audio_url, diarization, sentiment_analysis, summarization, and named_entity_recognition, all in a single request body.
Benchmarking diarization accuracy
Azure includes diarization with its batch transcription tier. Our diarization is powered by pyannoteAI's Precision-2 model, available exclusively in async workflows and included in the base per-hour rate on Starter and Growth plans. It is not available in real-time streaming. For real-time use cases, speaker attribution can be handled in post-processing once the async transcript arrives.
Accuracy across languages and dialects
Azure's base models can show accuracy errors on specific accents and regional dialects, and Microsoft's own Transparency Note documentation recommends Custom Speech training with representative accent and dialect data to address it. Our automatic language detection correctly identifies the speaker's language across most accents, though strong accents can occasionally trigger mis-routing, a limitation worth testing on your own audio distribution before deploying to accented-speaker populations. On the Hugging Face Open ASR Leaderboard's private conversational dataset, we rank #2 across both open-source and commercial models, providing independent third-party validation you can verify without relying on our own benchmarks.
Operational gains for your ASR pipeline
The migration is not just an API swap. It changes the operational profile of your ASR layer in ways that compound over time.
All-inclusive pricing without per-feature metering
Azure's billing model charges separately for base transcription, the diarization add-on ($0.30/hr on real-time), and downstream enrichment, where translation goes through Azure Translator and sentiment through Azure Text Analytics, each with its own billing meter and API call. We charge one rate that covers transcription plus diarization, translation, sentiment analysis, named entity recognition (NER), summarization, and custom vocabulary. The table below models the cost difference at realistic async/batch audio volumes, where diarization is included in both Azure's batch tier and our Starter and Growth plans, and our public pricing covers all audio intelligence features in a single rate.
Table 2: TCO comparison (async/batch, with diarization included)
| Monthly volume |
Azure batch transcription + diarization |
Gladia Starter ($0.61/hr) |
Gladia Growth (from $0.20/hr) |
| 1,000 hours/month |
~$1,300 |
~$610 |
~$200-$400 |
| 5,000 hours/month |
~$6,500 |
~$3,050 |
~$1,000-$2,000 |
| 10,000 hours/month |
~$13,000 |
~$6,100 |
~$2,000-$4,000 |
Azure estimate is based on batch transcription pricing. Verify current rates in Microsoft's Azure Speech pricing documentation before committing. Diarization is included in Azure's batch tier and in all our Starter and Growth plans at the rates shown. Growth pricing depends on volume commitment. Translation and sentiment are included in Gladia Starter and Growth plans and are not represented in the Azure column because they route through separate Azure services at additional cost.
Production accuracy on accented and noisy audio
Solaria-3 ranks #1 on Switchboard, the most challenging conversational dataset, ahead of AssemblyAI, Deepgram, ElevenLabs, Mistral, and Speechmatics, and is the only model under 7% WER on Earnings22 financial calls. That matters because every downstream system is ceiling-bounded by the accuracy of the transcript that feeds it: a wrong account number in a financial call transcript produces a wrong CRM entry, and a missed entity in a sales call produces a wrong coaching score. Gravite, a French CCaaS quality-monitoring platform, cut review time by 93% (from approximately 15 minutes to 1 minute per call) while processing 50,000 hours of audio per year, choosing us specifically for French-first accuracy and EU data sovereignty.
Offload model and GPU maintenance
Self-hosted Azure containers shift the hardware burden to your team: GPU provisioning, container image updates, capacity planning for peak load, and monitoring for inference failures. Even managed Azure Speech carries version management overhead when models update. Moving to a managed API eliminates that entire class of toil. Aircall, which processes more than 1M calls per week through Gladia, cut transcription processing time by 95% (from 30 minutes to 1.5 minutes per call) after switching.
Deploy our APIs within 24 hours
The Python and JavaScript SDKs are lightweight enough that most teams reach production in under a day. Direct access to our engineers, not a ticket queue, removes the support bottleneck from the critical path. Before writing any integration code, install the Skills context files with npx skills add gladiaio/skills to give Cursor or Claude Code accurate, hallucination-free knowledge of the API surface.
Identifying migration friction points
Replacing on-premises ASR pipelines
If you're running Azure Speech containers locally to satisfy air-gapped requirements, our dedicated cloud clusters in EU and US won't satisfy that constraint. We can handle data sovereignty and GDPR boundary requirements through our EU cluster, but if your security architecture requires zero external network path for audio data, this is a hard constraint, not a soft limitation to work around. Our call center compliance coverage documents how GDPR, PCI DSS, and HIPAA apply to contact center audio for all other regulated requirements.
Refactoring custom training pipelines
Azure Custom Speech training pipelines typically involve acoustic model adaptation, language model weighting, and endpoint deployment automation. None of that infrastructure maps directly because our base models eliminate the need for it on most real-world audio. The migration path is to run parallel evaluation on your production audio distribution first, measuring whether our out-of-the-box accuracy matches your custom model's performance on your specific conditions before refactoring any endpoints.
Mapping Azure API to Gladia flows
Table 3: Batch transcription API parameter mapping
| Azure Batch Transcription |
Gladia pre-recorded API |
Notes |
contentUrls |
audio_url |
Single URL per request |
locale (e.g., en-US) |
language_config.languages (e.g., ["en"]) |
ISO 639-1 codes, passed as an array |
diarizationEnabled: true |
"diarization": true |
Async only in Gladia |
Ocp-Apim-Subscription-Key header |
x-gladia-key header |
API key authentication |
| Poll transcription result URL |
Poll GET /v2/pre-recorded/{id} using the id returned at submission, or call the result_url returned in the same response, until status is done (or use webhook callback) |
Different endpoint structures. Gladia also supports webhooks |
wordLevelTimestampsEnabled: true (default: false) |
Included in standard response structure |
Azure requires explicit opt-in. Gladia returns timestamps as part of the standard response object |
| Custom speech endpoint URL |
model: "solaria-3" or "solaria-1" |
Model selection via parameter |
The key difference is that our single request includes features Azure routes through separate services:
Azure Speech batch transcription (REST):
```json
POST https://{YourResourceName}.cognitiveservices.azure.com/speechtotext/transcriptions:submit
Ocp-Apim-Subscription-Key: {azure-key}
Content-Type: application/json
{
"contentUrls": ["https://your-storage.blob.core.windows.net/audio.wav"],
"locale": "en-US",
"displayName": "My Transcription",
"properties": {
"diarizationEnabled": true,
"wordLevelTimestampsEnabled": true
}
}
```
Gladia async transcription (REST):
```json
POST https://api.gladia.io/v2/pre-recorded
x-gladia-key: {gladia-key}
Content-Type: application/json
{
"audio_url": "https://your-storage.blob.core.windows.net/audio.wav",
"diarization": true,
"sentiment_analysis": true,
"summarization": true,
"named_entity_recognition": true,
"language_config": {
"languages": ["en"],
"code_switching": false
},
"model": "solaria-3"
}
```
The request above includes diarization, sentiment analysis, summarization, and NER in the same call at no additional cost on Starter and Growth plans, while the Azure equivalent requires separate calls to Azure Text Analytics and Azure Translator.
Assessing your current Azure Speech architecture
Run these four steps before touching production configuration.
1. Test Gladia against your production audio
Upload representative samples from your actual audio distribution (not clean test recordings) and compare transcripts on the conditions that matter: accented speakers, noisy environments, overlapping speakers, or code-switched conversations. The blind comparison tool is a fun and useful tool to do this: it strips out provider branding so you pick the better transcript before seeing who produced it. Use it as a gut check, then follow with a reproducible benchmark on your full audio distribution.
2. Model total cost at 1x, 5x, and 10x volume
Take your current monthly Azure audio hours and multiply by our per-hour rate, including all the features you currently pay for separately. Use the Growth plan rate (from $0.20/hr at volume commitment) for projections at 5x and 10x volume.
3. Validate data residency and DPA requirements
Our compliance posture covers SOC 2 Type II, ISO 27001, HIPAA, GDPR, PCI DSS, and HDS (Hébergeur de Données de Santé, France's mandatory framework for hosting personal health data). On Growth and Enterprise plans, customer audio is never used to retrain our models, and no opt-out action is required.
4. Review vendor uptime and SLA data
Check our public status page for historical uptime data before committing. We maintain 99.9%+ uptime. Enterprise plans include SLA guarantees and dedicated cloud cluster options across EU and US regions.
Mapping your migration path from Azure Speech
A phased cutover protects against regression while giving you a controlled rollback path at each stage.
1. Run parallel benchmark tests
Before switching any production traffic, run your existing Azure transcription jobs in parallel with Gladia using the same audio files. Compare WER on a held-out set of manually-verified reference transcripts from your own domain. This validates whether our base model matches or exceeds your Azure custom model's performance on your specific audio distribution. The async benchmark methodology is fully open and reproducible for cross-referencing against your own test conditions.
2. Map Azure API calls to Gladia endpoints
Use the parameter mapping table above as your primary reference. Pay attention to language code format differences (Azure uses en-US locale strings, Gladia uses ISO 639-1 codes like en) and the model selection parameter (solaria-3 for European business audio, solaria-1 for real-time streaming or broader language coverage). If you are also updating from an earlier Gladia integration, the pre-recorded V1-to-V2 changes and live transcription V1-to-V2 changes apply to both surfaces.
3. Migrate async transcription workloads first
Async is the lower-risk migration because failure surfaces as a delayed or degraded transcript rather than a live user experience break. Move batch processing jobs first, validate accuracy and JSON output structure, then run production traffic in shadow mode (sending audio to both Azure and Gladia, comparing outputs) before switching the primary response source. Migrating async pipelines before touching real-time is the recommended sequence: it establishes a validated accuracy baseline on your audio distribution before you take on the added complexity of live streaming, and all audio intelligence enrichments (diarization, sentiment, NER, summarization) are returned in the same async response.
4. Failover strategies for live streaming
For real-time streaming, implement a feature flag in your own application layer that controls which provider receives WebSocket connections. Keep the Azure Speech SDK initialized during the switchover window so you can fall back to Azure if session initialization fails on our side, for example, by checking the HTTP response code before opening the WebSocket and routing accordingly. This gives you a flag-controlled rollback path without a code deployment. Once you've validated latency and accuracy on production traffic, toggle the flag fully and decommission the fallback path.
5. Configure alerts for ASR health
Set up monitoring on transcript latency (time from audio submission to response) and error rates (non-200 responses from the API). Datadog custom metrics work well for this pattern. Add a webhook callback to receive transcript-complete notifications rather than polling, which reduces latency monitoring overhead.
6. Decommission Azure Speech resources
Once you've validated clean production traffic through Gladia, suspend or disable Azure Speech endpoints to stop incurring charges, cancel any running custom speech model training jobs, and remove Ocp-Apim-Subscription-Key from your secrets manager. As a cleanup step, consider archiving or deleting audio files stored in Azure Blob Storage that were uploaded solely for transcription, and deprovision any Azure Container Instances used for local container deployments, both to eliminate continued billing on resources that no longer serve production traffic.
Migrating your inference calls to Gladia
Migrating batch transcription workflows
The async migration follows these steps:
- Replace the endpoint: Swap your Azure batch URL for
POST https://api.gladia.io/v2/pre-recorded. - Replace the auth header: Change
Ocp-Apim-Subscription-Key to x-gladia-key. - Restructure the request body: Replace
contentUrls array with audio_url string, and move feature flags (diarization, sentiment, NER) directly into the request body rather than calling separate services. - Update the polling logic: The initial response returns an id and a ready-to-use
result_url. Poll GET https://api.gladia.io/v2/pre-recorded/{id} (or call the returned result_url directly) until status returns done, then parse the result object for transcript, speaker labels, and enrichment outputs.
Real-time stream migration steps
- Generate a session token: POST to
https://api.gladia.io/v2/live with your x-gladia-key header to receive a session-scoped WebSocket URL. - Connect to the session URL: Open a WebSocket connection to
wss://api.gladia.io/v2/live?token={token}. - Send configuration message: Transmit a JSON config object specifying
encoding, sample_rate, language_config (an object with a languages array and a code_switching flag), and model (use "solaria-1" for real-time, as Solaria-3 is async only). - Stream audio frames: Send raw audio as binary WebSocket frames, or, if your client can't send binary, wrap base64-encoded audio in a JSON message shaped
{"type": "audio_chunk", "data": {"chunk": "<base64-encoded>"}}. The older flat "frames" field was replaced by this structure in the V2 API. - Parse responses: Each transcript message has
type: "transcript" with a nested transcription object containing transcript (the text), words (with timestamps), and is_final (a boolean distinguishing partial from final results), as shown in the real-time transcription tutorial for React.
Mapping diarization in your pipeline
Diarization is async-only. The response JSON from a completed async job includes a utterances array where each object carries speaker, start, end, and text fields. The speaker field value is an integer index (0, 1, 2...) assigned in the order speakers appear in the recording. Replace SpeechRecognitionResult.speakerId (Azure's speaker identifier reference in your pipeline code, typically speakerId on conversation transcription results, though the exact property varies by SDK scenario) with the integer speaker field from our utterance objects.
Handling Azure Speech transition hurdles
- Mapping custom vocabulary to Gladia: Azure Custom Speech requires uploading pronunciation lexicons and language model training data to improve recognition of domain terms. Our custom vocabulary accepts a list of terms as a JSON parameter in the API request body, applied at inference time without any training cycle. Format your terms as either a plain list of strings, or as objects with a
pronunciations field when you need to specify how a term actually sounds, as documented in our custom vocabulary guide. Run parallel evaluation on your production audio distribution to verify whether our base model plus a custom vocabulary list matches your custom model's performance on domain terms before committing. - Reducing inference delay: For real-time pipelines, the primary latency lever is audio frame size. Smaller frames reduce buffering delay before the first partial arrives but increase WebSocket message overhead. Ensure your WebSocket client uses binary frames rather than text-encoded base64 for audio payloads, which reduces serialization overhead. Solaria-1 delivers partials under 103ms and final transcripts around 270ms on standard audio.
- Scaling throughput: Our managed infrastructure scales concurrent requests without pre-provisioning. You don't need to request a quota increase or forecast peak capacity before a high-traffic event. Concurrent sessions scale automatically without pre-provisioning, which means a contact center processing thousands of simultaneous calls doesn't require a separate capacity planning conversation with our team. For CCaaS platforms specifically, this eliminates one of the more painful Azure operational tasks: capacity buffer management before campaign peaks.
The migration pattern above replaces a fragmented, maintenance-heavy infrastructure layer with a single managed API endpoint. Engineering capacity that previously went into custom model retraining, container provisioning, and multi-service billing reconciliation routes back to your product backlog. That is the operational shift the rest of this guide is built around.
Start with €50 in free credits and have your integration in production in less than a day.
FAQs
How long does a typical migration from Azure Speech to Gladia take?
Most engineering teams complete the API refactoring in under 24 hours, with the async pipeline typically validating in staging before you touch live streaming workloads.
Are diarization and translation charged as add-ons like Azure?
No, all audio intelligence features including diarization, translation, sentiment analysis, summarization, and named entity recognition are included in the base per-hour rate on our Starter and Growth plans.
What does a projected switchover schedule look like?
A small team typically completes the endpoint transition and initial production validation in under 24 hours, with the exact sequence depending on pipeline complexity. Enterprise teams with more complex pipeline dependencies should expect additional time proportional to the number of downstream systems that consume transcript outputs.
How do I sync Azure and Gladia workflows during the transition?
Use feature flags to control traffic routing at the session level. Send audio to both providers simultaneously during the shadow testing phase, compare transcript outputs, and monitor error rates and latency in parallel before toggling the flag to full routing through Gladia.
How do your base models compare to Azure's custom-trained models?
On real-world business and conversational audio, Solaria-3 ranks #1 across English and core European languages on benchmarks covering noisy, conversational, and production audio, without any custom training cycle. The parallel testing step in the migration path above is the definitive way to verify this against your own audio distribution before committing.
Do you support the same languages as Azure?
Azure supports 140+ locales across its supported languages. Solaria-1 supports 100+ languages, including Tagalog, Bengali, Punjabi, Tamil, Urdu, Persian, and Marathi, making our coverage deeper in Southeast Asian and South Asian languages while slightly narrower in total count.
What are the procedures for model rollbacks?
Because we operate as a managed API rather than a self-hosted model, rollback means restoring your Azure Speech endpoint configuration, which you can do instantly via a feature flag toggle if you kept the Azure SDK connected during the cutover window per the failover strategy above. Our API uses explicit versioning (e.g., /v2/), so verify the endpoint version your integration targets before executing a rollback to confirm schema compatibility.
Key terms glossary
Word Error Rate (WER): The standard metric for measuring transcription accuracy, calculated as the number of substitutions, insertions, and deletions divided by the total number of words in the reference transcript.
Diarization Error Rate (DER): The metric for evaluating speaker attribution accuracy in multi-speaker audio, measured as the sum of missed speech, false alarm speech, and speaker misclassification error as a percentage of total reference speaker time.
Code-switching: The practice of alternating between two or more languages or dialects within a single conversation, a common pattern in multilingual contact center and meeting audio that most base ASR models handle poorly without explicit support.
