DeveloperDeveloper Enablement — Azure Functions
Azure Functions in-process model is retiring in November 2025. If you are running. NET functions using the in-process hosting model, you need to migrate to the isolated worker model. Microsoft has been warning about this for a while, but the deadline is now here. Plan your migration before your functions stop working.
Editorially reviewed for factual accuracy
Microsoft will retire the Azure Functions in-process hosting model on , pushing every. NET workload to the isolated worker model well before that date.1 Engineering leaders need to budget migration sprints now so production functions stop depending on the legacy worker, Windows-only bindings, and process-shared state that disappear once the retirement lands.
The in-process worker already lost. NET 6 support when Microsoft ended the runtime’s lifecycle on , leaving. NET 8 as the only supported target for in-process apps.12 Teams that delay the move to the isolated worker will face a compressed runway to rework dependency injection, diagnostics, and extension registration once Microsoft fully blocks in-process deployments.
Impact on function apps and pipelines
- Hosting architecture: The isolated worker model runs functions out-of-process, so teams must redesign middleware, singleton usage, and cold start tuning that previously assumed in-process execution inside the Functions host.1
- Runtime patching: Remaining on in-process ties workloads to. NET 8 with no path to future LTS releases, undermining security baselines and delaying access to new Azure Functions features once. NET 9 and. NET 10 arrive.12
- CI/CD and extension packaging: Migrating to isolated changes how triggers, bindings, and logging extensions load, requiring updates to build pipelines, integration tests, and observability baselines.
Actions to schedule before Q1 2026
- Audit every Azure Functions app for in-process usage and prioritize workloads with premium plans or dedicated Windows workers so you can rehearse isolated deployments without impacting consumption-plan cold start SLAs.
- Refactor dependency injection, configuration loading, and logging to the isolated programming model, validating that bindings and durable functions behave consistently across staging environments.1
- Update runbooks, extension bundles, and platform documentation to codify the new worker model and the. NET 8 minimum so developers stop creating new in-process apps ahead of the November 2026 cutoff.12
Best practices for teams
Development teams should adopt practices that ensure code quality and maintainability during and after this transition:
- Code review focus areas: Update code review checklists to include checks for deprecated patterns, new API usage, and migration-specific concerns. Establish review guidelines for changes that span multiple components.
- Documentation updates: Ensure README files, API documentation, and architectural decision records reflect the changes. Document rationale for setup choices to aid future maintenance.
- Version control practices: Use feature branches and semantic versioning to manage the transition. Tag releases clearly and maintain changelogs that highlight breaking changes and migration steps.
- Dependency management: Lock dependency versions during migration to ensure reproducible builds. Update package managers and lockfiles systematically to avoid version conflicts.
- Technical debt tracking: Document any temporary workarounds or deferred improvements introduced during migration. Create backlog items for post-migration cleanup and improvement.
Consistent application of development practices reduces risk and accelerates delivery of reliable software.
Maintenance outlook
If you are affected, plan for ongoing maintenance and evolution of systems affected by this change:
- Support lifecycle awareness: Track support timelines for dependencies, runtimes, and platforms. Plan upgrades before end-of-life dates to maintain security patch coverage.
- Continuous improvement: Establish feedback loops to identify improvement opportunities. Monitor performance metrics and user feedback to guide iterative improvements.
- Knowledge management: Build team expertise through training, documentation, and knowledge sharing. Ensure institutional knowledge is preserved as team composition changes.
- Upgrade pathways: Maintain awareness of future versions and breaking changes. Plan incremental upgrades rather than large leap migrations where possible.
- Community engagement: Participate in relevant open source communities, user groups, or vendor programs. Stay informed about roadmaps, good practices, and common pitfalls.
preventive maintenance planning reduces technical debt accumulation and ensures systems remain secure, performant, and aligned with business needs.
- Test coverage analysis: Review existing test suites to identify gaps in coverage for affected functionality. Prioritize test creation for high-risk areas and critical user journeys.
- Regression testing: Establish full regression test suites to catch unintended side effects. Automate regression runs in CI/CD pipelines to catch issues early.
- Performance testing: Conduct load and stress testing to validate system behavior under production-like conditions. Establish performance baselines and monitor for degradation.
- Security testing: Include security-focused testing such as SAST, DAST, and dependency scanning. Address identified vulnerabilities before production deployment.
- User acceptance testing: Engage teams in UAT to validate that changes meet business requirements. Document acceptance criteria and sign-off procedures.
A full testing strategy provides confidence in changes and reduces the risk of production incidents.
In-process to isolated worker migration
Migrating from in-process to isolated worker model involves dependency injection pattern changes, binding configuration updates, and potential cold start performance differences. Test function behavior thoroughly in staging environments before production cutover. The isolated model provides better runtime version flexibility but requires code modifications.
Consider migration as an opportunity to modernize to. NET 8 and adopt the latest Azure Functions SDK features simultaneously.
Dependency injection and startup configuration
The isolated worker model uses a different dependency injection approach. Startup configuration moves from FunctionsStartup to HostBuilder patterns. Review service registrations, configuration providers, and middleware to ensure proper initialization in the isolated model.
Bindings configuration syntax differs between in-process and isolated models. Update function attributes and connection string references according to the isolated worker SDK documentation.
Performance and monitoring considerations
The isolated worker model runs functions in a separate process from the host, which may affect cold start latency. Benchmark performance in staging environments and consider provisioned concurrency or premium plans for latency-sensitive workloads.
Application Insights integration requires explicit configuration in the isolated model. Verify telemetry collection, custom metrics, and distributed tracing continue functioning after migration.
Multi-region and slot deployment strategies
Deployment slots enable blue-green deployment patterns for isolated worker functions. Test new versions in staging slots before swapping to production. Multi-region deployments require coordinated migration across all regions to maintain consistent runtime versions.
Why Microsoft Is Making This Change
Platform migrations are never fun, but they are often necessary for progress. Microsoft's decision to retire the in-process model reflects lessons learned about isolation, security, and supportability. The isolated worker model might require more initial setup, but it is more robust in the long run.
If you have been putting off this migration, the deadline makes your decision for you. Better to migrate on your own timeline than scramble when support ends.
Migration Without the Headaches
The good news? Microsoft has made the migration path clearer than most platform changes. The isolated worker model offers better separation between your code and the platform, which means fewer mysterious runtime issues.
Start with your least critical functions. Learn the migration patterns, find the gotchas, and build confidence before tackling your production workloads. Migration is a skill—practice on lower-stakes projects first.
Continue in the Developer pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Secure Software Supply Chain Tooling Guide
Engineer developer platforms that deliver verifiable provenance, SBOM distribution, vendor assurance, and runtime integrity aligned with SLSA v1.0, NIST SP 800-204D, and CISA SBOM…
-
Developer Enablement & Platform Operations Guide
Plan AI-assisted development, secure SDLC controls, and runtime upgrades using our research on GitHub Copilot, GitHub Advanced Security, and major language lifecycles.
-
Continuous Compliance CI/CD Guide
Implement CI/CD pipelines that satisfy NIST SP 800-218, OMB M-24-04 secure software attestations, FedRAMP continuous monitoring, and CISA Secure-by-Design guidance while preserving…
Documentation
- Azure Functions Model Retirement — Microsoft
- Azure Functions Migration Guide — Microsoft
- NIST Cloud Computing — NIST
Comments
Community
We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.
No approved comments yet. Add the first perspective.