The public sector handles sensitive citizen data, which is why software projects built with secure coding are imperative to deliver high trust levels. Code compliance with data protection laws, financial governance standards, and various regulations and policies is an obligation that must be consistently met to maintain trust and accountability.

According to IBM’s Cost of a Data Breach Report 2026, the global average cost of a data breach is $4.99 million. That’s a lot of money for any organization in the public sector. Similarly, the Ponemon Institute and Globalscape’s report, The True Cost of Compliance with Data Protection Regulations, determined that the cost of non-compliance is 2.71 times higher than being compliant. Hardcoded credentials or insufficient input/output validation are common, costly issues, often caused by working at speed and incomplete validation checks.

Many issues create compliance problems, and poor code security is one of the biggest risks, which code maintainability can mitigate. Ensuring compliance also helps avoid the costs associated with productivity loss, financial penalties, legal fees, and settlements that can quickly add up after a breach.

Understanding the risks of non-compliance in the public sector when building and updating software and taking steps to ensure code compliance helps avoid financial and reputational damage.

Try Qodana

Public sector software compliance cheat sheet

Strict standards apply across public sector software for data protection, security controls, accessibility, and supply chain transparency. Compliance with specific regulations, frameworks, and standards is mandatory, but may vary depending on your location and the applicable policies.

Our cheat sheet helps developers working on public sector software understand potential compliance risks, the considerations to make, and how using a code quality tool can help ensure compliance. It outlines common issues for public sector software, so your development team can review its code quality against each factor before deployment to minimize any risks. 

Save time, stay safe, and ensure you’re not breaking any rules.

Compliance Risk	Dev Consideration	Code Quality Tool Use
Non-uniform delivery quality breaches contract standards, resulting in disputes over “whose code failed”	Inconsistent coding standards across contractors and subcontractors	Automatic enforcement of centrally configured quality profiles across all teams
Institutional knowledge loss leading to undetected regressions in critical systems	Dev teams change over long lifecycles, causing quality drift	Baking continuous inspection into the CI/CD pipeline, regardless of who writes the code
Rising maintenance costs and risks breaching long-term supportability commitments in contracts	Unchecked code smells, duplication, and complexity accumulate	Track technical debt metrics on an ongoing basis
Breach of secure development lifecycle mandates with potential data breaches exposing citizen data	Injection flaws, insecure deserialization, and unsafe input handling	Static application security testing (SAST) detects known vulnerability patterns
Violation of identity and access management standards causes a credential leak risk	Hardcoded credentials or secrets in source code	Secret detection built into code scans
Non-compliance with data protection laws (e.g. GDPR), which require appropriate security measures	Weak or outdated cryptography	Flags insecure crypto implementations
Supply chain security failure, which breaches vulnerability management requirements	Vulnerable open-source dependencies	Dependency vulnerability scanning
Breach of procurement restrictions on acceptable licenses that cause IP/legal exposure	License conflicts in dependencies	Automated license compliance checks
Unsupported components in production mean incident response and patching obligations aren’t met	Outdated libraries are no longer supported	Dependency freshness tracking
Failing to produce evidence during compliance audits or contract milestone sign-off	A lack of objective audit evidence for code quality/security	Automated and time-stamped historical reports
Audit findings cite inadequate or inconsistent quality assurance process	Relying on manual reviews as the sole compliance gate	Tool-generated reports replace subjective sign-off
Deliverable acceptance criteria breach and contractual SLA non-conformance	Non-compliant code progressing through the pipeline unchecked	Quality gates block merges/releases below the threshold
Business continuity risks during vendor/contractor handover	Inherited/legacy code with unknown risk areas	Complexity and risk for unfamiliar codebases surfacing
A breach of government IT policy restricts external SaaS/cloud dependencies	A need for on-prem/air-gapped tooling	Self-hosted deployment option

Code compliance risk 1: Security and data protection compliance

Failing to comply with security and data protection standards and regulations puts sensitive and personal information at risk of exposure. Public sector software processes large amounts of personal data. Aligning it with applicable security and data protection standards, such as the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018, is vital.

Requirements vary by country, too. For example, public sector bodies in EU countries must abide by General Data Protection Regulation (GDPR), a strict data privacy and security law, while UK central government departments and agencies are subject to the National Audit Office (NAO) standards. 

US agencies work within Federal Acquisition Regulation (FAR), Defense Federal Acquisition Regulation Supplement (DFARS), and Federal Risk and Authorization Management Program (FedRAMP).

The real-world impact for developers 

Developers must build privacy and defense procedures into the software development lifecycle (SDLC) from the start to protect sensitive data. Leaving it too late or considering security too close to testing and deployment can jeopardize privacy protection.

Using weak and outdated cryptography is another compliance risk, as it leaves public sector software vulnerable to attacks. Weak cryptography can also breach controls required under frameworks like ISO/IEC 27001 (Information Security Management), risking loss of certification and reputational damage.

Considering supply chain vulnerabilities and the accountability for personal data handled by third-party vendors is important, too. Third-party dependencies must be treated as active risks. Integrating a code compliance tool like Qodana into the IDE and CI/CD pipeline brings automated SAST checks, secret detection, and cryptography scanning directly into developers’ existing workflow, catching issues before they reach production.

Secure credential storage, explicit user-consent handling, penetration testing before deployment, and ongoing automated testing help with security and data protection compliance. This can ensure public sector software retains NCSC Cyber Essentials certification.

Code compliance risk 2: Contractual and procurement compliance

Public sector software can automate government purchasing and supplier agreements. This improves efficiency but may introduce compliance risks, such as service level agreement (SLA) non-conformance. Failure to comply with an SLA can result in contract termination and financial penalties.

Various regulatory guidelines cover contractual and procurement compliance. These include the FAR in the US and the UK Public Contracts Regulations 2015 (procurement law). Government departments can add specific rules and regulations, like the DFARS and the Cabinet Office Technology Code of Practice.

Potential risks include non-compliant code progressing through the pipeline unchecked, like committing an active API secret key to a feature branch and not running SAST, which can lead to a breach of deliverable acceptance criteria. Vague requirements and missing edge cases may cause this. It may also result in disputes over delivery quality across contractors due to siloed teams.

Open-source dependencies, risks and actions

Open-source dependencies often carry licensing terms too, such as copyleft clauses and commercial-use restrictions. These may conflict with procurement rules on acceptable software. An undetected license conflict can expose the public sector body to IP disputes or breach of contract. Automated license compliance scanning flags these conflicts at the dependency level, before they become a legal problem.

Developers should embed automated quality gates into the CI/CD pipeline, so non-compliant code can’t progress toward a contractual deliverable. This replaces manual sign-off with an objective and repeatable check that provides useful evidence if a dispute over delivery quality arises.

Code compliance risk 3: Audits and accountability

Failing to produce evidence during compliance audits results in unverified controls being treated as non-existent. For public sector software, this can lead to failed certifications and financial penalties. A digital paper trail is essential for objective audit evidence of code quality and security, ensuring accountability.

A reliance on subjective, manual sign-off alongside inconsistent findings from the quality assurance process risks audit failure. Lacking objective audit evidence for code quality and security also exposes public sector software to compliance failure and technical debt. Automated tools can replace subjectivity to help ensure compliance with relevant regulatory guidelines and audits.

The National Institute of Standards and Technology (NIST) provides guidelines for federal information systems and organizations, which apply to some public sector software in the US. There are also audit requirements of ISO/IEC 27001 and the National Audit Office (NAO) standards for public spending accountability in the UK.

Developers must automate audit reports, embedding automated controls within the SDLC to ensure compliance with audits. This also mitigates any risk from manual sign-off. Integrating testing and traceability into CI/CD pipelines creates a digital audit trail to help produce evidence during any compliance audit.

Code compliance risk 4: Long-term supportability and continuity

Public sector software failures can lead to critical citizen service outages. Long-term supportability enables the continuity of such software and the effective application of updates over time to maintain performance and security levels. It also helps compliance with relevant regulations and global standards, such as ISO 22301 (Business Continuity Management System). 

Any public sector software that relies on open-source code is also at risk of being built on libraries that become outdated. Incident response and patching obligations won’t be met due to unsupported components. There are also business continuity risks during vendor or contractor handovers, as teams may inherit code with unknown risk areas, where the complexity of an unfamiliar codebase can hide problems until it’s too late.

Prioritizing quick fixes can create technical debt and breach long-term maintenance commitments. A short-term patch that isn’t built for long-term support often needs revisiting later. That future fix is usually costlier and more time-consuming than doing it properly the first time.

Developers should implement dependency freshness tracking to identify and use the latest stable version or patch release. This minimizes potential security risks due to using outdated libraries and ensures public sector software is up-to-date.

Keeping the number of external dependencies to a minimum also makes long-term supportability easier. Automated unit and integration tests help catch bugs before deployment, while static code analysis catches code errors early, making it easier to address them and ensure long-term supportability.

Code compliance risk 5: IT governance and infrastructure policy

Public sector software must meet security baselines and comply with various regulatory guidelines for IT governance. For example, the UK’s Government Cloud First policy ensures public sector organizations use public cloud services as the default when procuring new or existing IT and software solutions.

Government IT policy often restricts the use of external SaaS or cloud dependencies. Using non-compliant tooling puts sensitive public sector data at risk. This can violate FedRAMP (Federal Risk and Authorization Management Program), a standardized approach based on NIST guidelines that ensures cloud providers meet strict federal data protection rules.

IT infrastructure is also at risk of erosion due to institutional knowledge loss linked to the governance of long-running systems. When developers and staff leave without documenting context, workarounds, and the rationale for decisions, it can make understanding and maintaining the infrastructure difficult. 

Digital audit trails

A digital audit trail helps with ongoing infrastructure maintenance. Development teams can also consider on-premises and air-gapped tooling as a self-hosted deployment option for better code compliance.

These secure systems require no external cloud dependencies. Embedding automated guardrails into the SDLC helps achieve compliance through continuous scanning and policy-as-code.

Discover more about using Qodana for DevOps to help ensure code compliance in public sector software projects or try Qodana for 30 days.

Try Qodana

Ryan sits down with Tim Lindholm, an early contributor to the Java language at Sun Microsystems, to chat about what it was like building one of the most popular programming languages ever at its inception, why it was strategically important for the Java team to create a cross-platform ABI to compete with Windows NT, and how applets were initially just an interesting demo.

Flexible Sections give SharePoint page authors the freedom to build layouts without a strict column structure, resizing, moving, and overlapping web parts freely within a section. That freedom is powerful, but it can also make it harder to keep pages predictable and consistent across the many ways people view them.

Today we're shipping a set of usability improvements designed to make flexible sections more predictable, easier to control, and faster to author, without giving up any of the flexibility that makes it useful in the first place. 

See this video with Katelyn Seemakurti and Vesa Juvonen for the live demo of new features.

Column layout guides

Flexible Sections now show visual layout guides that mirror the familiar column structures you already know from standard sections. These guides give your page an underlying sense of structure, so content reflows cleanly and predictably across email, mobile, and canvas resize.

When you add a web part to the canvas, it automatically matches the layout guide's column width, giving you a sensible starting point every time. And you keep full flexibility: resize, reposition, or overlap any web part whenever your design calls for it. The guides inform your layout; they don't constrain it.

Persistent grid layout guides

Sometimes you just want to see the structure while you plan. A new grid layout guides toggle in the page command bar lets you keep gridlines and layout guides visible the entire time you're authoring.

No more entering a drag or resize operation just to reveal the underlying grid. Flip the toggle on, and the guides stay put as a page-level setting, making it far easier to align content and plan your layout with intention.

Convert standard sections to Flexible Sections

Want to turn an existing page or section into flexible? You can now convert a standard section into a Flexible Section in a single click, directly from the section property pane.

Best of all, conversion is non-destructive. Your existing column structure (whether it's 1, 2, 3 columns, or a 1/3–2/3 split) is preserved, along with the placement and stacking order of every web part. There's no need to rebuild your page content; you get the flexibility of flexible sections while keeping the layout you already built.

Keep the feedback coming

None of this would be possible without the ongoing input from our customers and partners. Your feedback on layout consistency, authoring speed, and control has directly shaped these improvements to Flexible Sections, and we're grateful for the continued partnership as we keep making page authoring better.

Have thoughts on these updates, or ideas for what should come next? Let us know in the comments on this post or on the demo video. We read every comment, and your input helps shape our roadmap.

Every app built on an LLM will eventually move to a new model. The model you shipped may be retired, or a newer model may offer better quality, cost, or performance. Changing a model name in code from a retiring model such as gpt-4o to a newer one such as gpt-5.1 may take one line. That line hides a much larger migration. 

Model failures are often silent to the systems using the model and loud to users. Nothing crashes. Error rates stay flat. Every dashboard says the migration went fine. Meanwhile, responses change shape, summaries become longer and more hedged, JSON fields disappear, and tool calls fire in a different order. Users notice. Support queues grow. Downstream code that depended on the old behavior starts to break.

A successful migration preserves the application's behavior or improves it in measurable ways. That requires a repeatable process to detect drift, adapt safely, and prove quality before broad rollout.

The model migration process has six phases: Discover → Assess → Adapt → Validate → Roll out → Retire. This article explains what each phase looks like, which Microsoft Foundry tools support it today—including Azure OpenAI capabilities—and where teams still need to build around the platform. It then applies the process to a retail shopping assistant and points to additional resources in Go deeper at the end of this post!

Why migrate now

Every model has a retirement date. On Microsoft Foundry, generally available models typically ship with a retirement date about 18 months out, and older model families are actively replaced. For example, the model lifecycle and retirement schedule lists gpt-4o (2024-05-13) as retiring on October 1, 2026, with gpt-5.1 as its replacement.

What happens at retirement depends on how you buy capacity:

• Standard, Global Standard, and Data Zone Standard (pay-as-you-go) deployments are auto-upgraded on a rolling, region-by-region schedule. You control the timing with versionUpgradeOption set to one of: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired, or NoAutoUpgrade. NoAutoUpgrade means the deployment stops working at retirement. Priority Processing follows the same path.
• Provisioned (PTU) deployments are not auto-upgraded. You migrate them yourself, either in-place (traffic moves over a 20–30 minute window with no downtime) or side-by-side (stand up the new deployment, test, shift traffic, delete the old one).
• Batch deployments follow the side-by-side path: deploy the new model, resubmit jobs, retire the old deployment.

The developer problem is the same in every case: traffic eventually reaches a different model, but the platform cannot tell you whether the application still behaves as it did before. A responding endpoint does not prove that the app behaves correctly. A new model can change formatting, tone, tool-calling behavior, or JSON shape in ways that quietly break downstream code.

When should I migrate?

Start before the retirement date. Automatic upgrade handles the traffic transition for eligible deployments, but the team still owns behavioral validation. Provisioned deployments also require a manual migration.

Microsoft typically makes a replacement available in Global Standard about 90 days before retirement, in provisioned regions about 30 days before retirement, and in standard regions about two weeks before retirement. That gives you time to evaluate the new model on your own terms. Retirement dates cannot be extended.

You also do not need a deprecation notice to begin. If a newer model may improve quality, speed, or cost, run it through the process now. Waiting turns the switchover into a slow train wreck: responses drift, parsing becomes brittle, support tickets accumulate, and the team ends up debugging a model it did not choose on a date it did not pick. A deliberate migration makes the retirement date a formality and creates a process the team can reuse.

Who this is for

This process fits teams that own an LLM-powered feature inside a larger application and run migrations deliberately. It also applies to AI-native platform teams that centrally manage models for other application teams. The phases remain the same, though platform teams may run them faster and in parallel rather than in sequence. Fine-tuned workloads are out of scope here because they cannot be upgraded automatically, have separate training and deployment retirement schedules, and turn the Adapt phase into a distillation or retraining exercise rather than primarily prompt work.

The six phases

Foundry tools at a glance

Microsoft Foundry provide tools for each phase of the Model Migration Process. 

Breakdown of each phase

0. Prepare the test dataset

Before starting the six phases, build a set of representative inputs, expected outputs, and agreed success criteria. This dataset gates the middle of the lifecycle: Adapt needs inputs for replay, and Validate needs ground truth and scoring criteria.

Step 0 describes the workload rather than the candidate model, so it can begin during Discover, before the team selects a target. Build the dataset from captured production traffic or domain examples in .csv or .jsonl. If representative data is not available, use the simulator to generate synthetic inputs.

Two practices determine whether this work pays off:

• Instrument capture before you need it. Production content capture is opt-in and never retroactive. Log prompts, responses, latency, and token counts now so the team has traffic to evaluate later.
• Freeze the dataset. Keep inputs, ground truths, and success criteria fixed throughout the migration. If they change, source and target results are no longer comparable.

You also need an inventory of the model deployments your workload uses, including their deployment types (Standard, Provisioned, or Batch). For each source model, note its retirement date and suggested replacement from the Model retirement schedule.

1. Discover

Discover begins when something forces the team to consider a model change: a deprecation notice, a new generally available model, a cost or latency problem, or a capability gap. The phase ends with a decision to begin migration or stay on the current model if it remains stable, performs well, and is not approaching retirement.

Foundry tools. The model lifecycle and retirement schedule publishes retirement dates and suggested replacements. The Azure OpenAI model retirements documentation explains notification timing, including at least 60 days for generally available model retirements and at least 30 days for preview model retirements. It also explains how to configure Azure Service Health advisories and use the Models API for programmatic lifecycleStatus and deprecation checks. Those APIs provide the foundation for an internal discovery system.

Where it breaks. Customers may learn about a retirement through email, a service health alert, or a production error. By the time the right team sees the signal, it may already be deep into the deprecation window and heading toward retirement.

What your team provides. The schedule and Models API expose the data through a stable contract. Mature enterprises may add a thin notification layer that routes it to the right owners.

2. Assess

The team chooses a candidate target model and confirms that it is usable: the correct region and SKU, enough quota, and availability alongside the current model so rollback remains possible.

Assess also includes projecting monthly cost against historical traffic. Pricing structures change between model generations through reasoning tokens, cached input, structured-output overhead, and other factors. Those changes can move unit economics by 2x or more. For regulated workloads, compliance requirements such as BAA, FedRAMP, and regional Standard versus Global Standard availability may narrow the candidate list before quality testing begins.

Foundry tools. Start with the replacement suggested in the retirement schedule, then build a shortlist with model benchmarks, which compare quality, safety, cost, throughput, and latency. Use trade-off charts such as quality versus cost and the side-by-side model comparison for up to three models. Compare context windows, feature support such as function calling, structured output, and vision, and available endpoints. Confirm SKU, region, quota, and upgrade mechanics in the model retirements documentation.

Where it breaks. Teams face several plausible candidates, such as gpt-5.1, gpt-5.2, and a nano variant, without clear positioning between them. A selected model may be unavailable in the required region or SKU, a constraint that sometimes appears only after planning is underway. Historical traffic may also show that the new model costs substantially more, forcing an unplanned budget decision.

What your team provides. Public benchmarks should filter the candidate list, not make the final decision. Confirm the shortlist against the team's own workload. Build the monthly cost view from token logs and current pricing.

3. Adapt

Adapt is often the most time-consuming phase for embedded and product-facing workloads. Validate may take longer for regulated workloads.

First, replay the existing workload on the new model without changing it. This isolates changes caused by the model. Diagnose shifts in verbosity, reasoning depth, structured-output adherence, tool-call shape, and latency. Then update the application until it recovers or improves on the previous behavior.

Prompt editing is only one part of Adapt. A migration often changes four other surfaces:

• Parameters. temperature, top_p, max_tokens, and reasoning-effort controls may not map directly between generations. Some are unsupported by newer model families.
• Tool definitions. Argument names, descriptions, and required fields that reliably guided the old model may need clearer wording or tighter constraints.
• Output schemas. Structured-output behavior changes between models. A schema the old model followed loosely may need explicit constraints, or the new model may finally enforce it.
• Calling code. API and SDK differences, including Chat Completions versus Responses, streaming formats, and new or renamed request fields, can require code changes. Downstream parsers may also assume the old response shape.

For agentic and workflow workloads, schema and tool-call changes can outweigh prompt changes.

Foundry tools. Prompt Optimizer is available through the Optimize button below the system instructions field in the Agent playground. It restructures instructions, explains each change by paragraph, and supports iteration. For example, a team can add a constraint such as "keep the JSON schema exactly" and optimize again. It is a fast first pass for a prompt that would otherwise be rewritten by hand.

For agent workloads, agent optimization tunes instructions, tools, and model selection together. Prompt Optimizer and agent optimization are available in Microsoft Foundry, not Azure OpenAI. When production data is unavailable, the simulator can generate synthetic and adversarial inputs.

Where it breaks. Most migration time is spent in a manual diagnosis loop. Teams rerun prompts by hand, compare outputs by eye, and rarely record what changed or why. For agent builders, chat benchmarks may miss tool-call regressions such as extra fields, renamed arguments, or changed call sequences. Those problems appear only when the team replays real agent traces.

Plan for three constraints:

• Start with the optimizers, then verify their output. They apply general practices in a single pass rather than fitting changes to the team's dataset. They tune instruction text, not tool definitions or output schemas. Copy the original prompt first because there is no version history, then evaluate the optimized prompt against the frozen dataset.
• Expect more manual work when moving between providers or model families. There is no "optimize for target model X" flow. Moving from one family to another, such as OpenAI to Claude, still requires deliberate prompt and schema translation.
• Record traffic before you need it. Replay is only as useful as the captured data. Existing traces are available as an evaluation source for agents today, while content capture is opt-in and never retroactive. Log prompts, responses, latency, and tokens now to prepare for the next Adapt phase.

4. Validate

Run the adapted workload against a quality rubric on the frozen dataset. The rubric may combine rules, LLM-as-judge evaluation, human review, existing user-feedback signals, or a domain-specific scoring framework. Examples include a clinical summarization rubric for healthcare or a tool-call sequencing assertion for agents.

Validation produces a pass-or-fail decision for production exposure. AI-native teams may run the same signal continuously on every commit rather than treating it as a one-time gate.

The dataset is a dependency for both Adapt and Validate. Build and freeze it early, around Assess, even though its primary purpose belongs to this phase. Validation then has two touchpoints:

1. Before Adapt, freeze the dataset and success criteria, then run the current model to establish the source baseline.
2. After Adapt, run the target model against the same dataset and evaluators, compare it with the source baseline, and make the release decision.

Prepare the evaluation runner early and apply the gate after Adapt. Both steps belong to Validate.

Foundry tools. The Azure AI Evaluation SDK, installed with pip install azure-ai-evaluation, includes more than 30 evaluators. They cover grounding, relevance, retrieval, coherence, fluency, question answering, reference-based similarity, F1, BLEU, ROUGE, safety, agent behavior, and Azure OpenAI graders. Teams can also build custom LLM-as-judge evaluators for task-specific rubrics.

The portal evaluation flow runs the same evaluators against model, agent, dataset, and trace targets. Run identical evaluators against source and target outputs on the frozen dataset so the results remain comparable.

Measure the three dimensions used for sign-off:

• Quality: evaluator results
• Latency: leaderboard time to first token and throughput, plus operational latency from the workload
• Cost: (input tokens × input price) + (output tokens × output price)

Where it breaks. Most teams do not have an evaluation suite. Teams that do often built it themselves and may not use platform evaluation tools. Regulated workloads add mandatory human review, which can become the bottleneck. For those teams, migrations often stall in Validate rather than Adapt.

What your team provides. The evaluators are ready to run, but model workloads still require teams to curate a domain-relevant test set from production traffic. That is why Phase 0 pays for itself.

5. Roll out

Promote the validated configuration in stages: non-production, then a canary or weighted percentage of production traffic, followed by broader exposure. Compare live latency, errors, and quality signals with the pre-migration baseline, then commit or roll back.

Some workloads cannot expose a new model to customer traffic during testing, including flows involving protected health information or financial transactions. Use shadow or mirror mode instead: run the new model offline against production inputs and compare its outputs with the old model without affecting users.

Foundry tools. Migration mechanics depend on the deployment SKU:

• Standard, Global Standard, and Data Zone Standard deployments upgrade automatically on a rolling schedule. Control timing with versionUpgradeOption: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired, or NoAutoUpgrade. Priority Processing follows the same path.
• Provisioned, Global Provisioned, and Data Zone Provisioned deployments migrate manually, either in place during a 20-to-30-minute Azure-managed traffic transition or through side-by-side deployments.
• Batch deployments migrate side by side. Deploy the new model, resubmit jobs, then retire the old deployment.
• Fine-tuned deployments do not upgrade automatically. They follow separate training and deployment retirement schedules, so plan retraining or distillation early.

See the model retirements documentation for deployment-specific guidance.

Use continuous evaluation to score a sample of production traffic in the Foundry Observability dashboard. Connect evaluation results to traces for root-cause analysis and configure Azure Monitor alerts for quality regressions.

Where it breaks. Offline evaluation can miss production quality and latency regressions. Rollback decisions may also be forced by deprecation deadlines rather than evidence.

What your team provides. Teams implement weighted routing between deployments in their application or gateway layer. They must also choose how long to keep the old deployment warm for rollback. Embedded copilot teams often target about 30 days. Design both mechanisms once and reuse them for future migrations.

6. Retire

Retire is easy to forget. Decommission the old deployment, free its capacity, archive evaluation artifacts, update internal documentation, and communicate the change to downstream owners. That may include customer-facing documentation, marketing pages, support runbooks, and audit logs. Regulated workloads may need to retain artifacts for years.

Retirement is also a governance step.

Foundry tools. Use the Models API to confirm that the old version is retired through lifecycleStatus or 410 Gone. Use the observability dashboard to confirm that the active deployment count falls. Add useful production traces to the golden dataset so the next migration starts with better evidence.

Where it breaks. Teams skip the phase. Zombie deployments accumulate, leaving teams with structural debris from migrations they never finished.

What your team provides. The observability dashboard shows deployment count, but the team must decide which deployments still carry traffic. Create an explicit retirement ticket rather than relying on someone to remember. Embedded copilot teams also need to update public claims such as "powered by gpt-4o" after the model changes.

Worked example: Zava's Shopping Assistant migrates from gpt-4o mini to gpt-5.x

Zava is a fictional retailer used as a stand-in for a real customer story. The example reflects patterns observed in customer-facing embedded AI workloads.

Zava's Shopping Assistant is one of the company's largest LLM workloads. It has two LLM stages:

1. Per-review insight extraction identifies sentiment, attribute mentions, and defect signals across thousands of product reviews.
2. Product-level summaries present those findings to shoppers on the product page.

Together, the two stages account for a meaningful share of Zava's token volume.

Discover

Zava's central AI Platform team made gpt-5.x models available internally and notified feature teams. The Shopping Assistant team learned about the models through that channel and received a target migration window before gpt-4o mini's deprecation.

Zava has an internal discovery layer built on the retirement schedule and Models API. Microsoft provides the underlying data, while Zava routes the signal to application owners.

Assess

The team compared gpt-5.4 nano, which offered lower latency and cost, with gpt-5.1 and gpt-5.2 using leaderboard trade-off charts. Selection remained difficult because of the rapid release cadence, unclear positioning between variants, and the lack of a behavioral benchmark for product question-and-answer workloads.

Capacity planning required coordination with the AI Platform team. Both gpt-4o mini and the gpt-5.x candidate needed to remain available in the same regions so the team could roll back.

Adapt

The team ran its existing Shopping Assistant prompts against gpt-5.4 nano using a sanitized traffic sample. Customer queries were scrubbed of personally identifiable information before replay.

The behavioral comparison found three problems:

• Summaries used more hedged language and sometimes contradicted the underlying review evidence, creating a shopper-trust risk.
• Insight counts varied across runs. The model sometimes extracted substantially more or fewer attribute mentions than gpt-4o mini, affecting downstream filtering.
• Latency varied more than expected on the synchronous product-page path.

Prompt Optimizer helped restructure the summary prompt, but the team still diagnosed the differences manually. It built its own replay system and behavioral comparison on top of captured traffic. Reengineering took weeks and extended beyond prompts: parameters and downstream parsing for the insight-extraction output also changed.

Validate

The team scored outputs with Zava's Product Answer Quality (PAQ) rubric. Its nine criteria cover factual grounding, attribute accuracy, tone, and refusal behavior for questions outside the catalog. Zava implemented the rubric as custom evaluators in the Azure AI Evaluation SDK.

Initial evaluations used unchanged prompts to isolate model behavior. The team reran them after each prompt change. Zava's QA team also completed a manual review, which the company requires for every new model used in a customer-facing workflow.

The per-review insight extraction stage still has no automated evaluation, a gap the team has accepted for now.

Roll out

The validated configuration moved to non-production and then through staged exposure: employees first, followed by a small percentage of shoppers.

The canary exposed latency regressions that offline evaluation had missed. The team rolled back the latency-sensitive synchronous product-page path while keeping the offline pregeneration path on the new model.

Retire

Retirement is not complete. The gpt-4o mini deployment remains warm for rollback. The team must resolve the synchronous-path latency regression before retiring it, which sends that code path back to Adapt.

This split state is common. Retire can lag Roll out by weeks or months, and the old deployment remains visible in deployment-sprawl data.

Lessons from the example

• Adapt consumed most of the schedule. Replay tooling, behavioral comparison, and prompt reengineering are the clearest opportunities for Microsoft to shorten migrations.
• Validate worked because Zava had invested in it. Most customers do not have an equivalent to PAQ. Making domain-specific evaluations cheaper to build would improve confidence in this phase.
• The migration is partially live and partially rolled back. The process must support split-state workloads rather than assuming a binary switch from old model to new.

How to use this process

The six phases can serve as a checklist and an interview script for teams creating or auditing a migration process.

• Documentation and process: Lead with the six phases. Most teams recognize them immediately.
• Investment priorities: Start with Adapt and Validate. Across customer stories, those phases consume the most time and confidence.
• Interviews and postmortems: For each phase, ask whether it happens, who owns it, which tool the team uses, where it failed last time, and what evidence would increase confidence.
• Metrics: Discover and Retire are the easiest phases to instrument through measures such as announcement reach and active deployment count. Adapt and Validate require purpose-built telemetry that most teams do not yet have.

Go deeper

Two companion resources turn the process into concrete implementation steps:

• Microsoft Learn guide: This article follows the six phases through identifying affected deployments, preparing a test dataset, adapting prompts, evaluating source and target models, and rolling out by deployment type.
• Foundry Models Accelerator: This community toolkit includes a deployment-inventory scanner, a feasibility and assessment playbook, code and API migration audit scripts, an A/B evaluation runner with golden datasets, and rollout guidance. It follows the same six-phase process. The Foundry Models Accelerator is a community-built toolkit provided as-is under the MIT License. It falls outside Microsoft Support. Always verify model availability and retirement dates against official documentation. 

Additionally, check out the Foundry Forgebook which hosts a plethora of recipes that walk through the required code changes to migrate from different source to target models, even across model families. 

The goal of a model migration is to change the model without changing your application’s behavior, or to change it measurably for the better. Lead with the six phases, invest first in Adapt and Validate phases, and treat the Retire phase as a governance step. 

Welcome to the August 2026 edition of What's New in Microsoft Copilot! Every month, we highlight new features and enhancements to keep Microsoft 365 customers up to date with Copilot features that help your users be more productive and efficient in the apps they use every day.

Let’s take a closer look at what’s new this month:

 

User capabilities: 

• More control for effort level and cost in Cowork
• Text selections, session sharing, and more for Copilot Chat
• New ways to work in Copilot Notebooks
• Change languages for meeting recaps with Copilot in Teams
• Hyperlinks, image understanding, and highlights for Copilot in Word
• Chat history and change history skill for Copilot in Excel
• Personal skills in Copilot in SharePoint
• Agents, email drafting, and management enhancements for Copilot in Outlook
• Improved file capabilities with Copilot in OneDrive
• Status reports and task enhancements for Copilot in Planner
• New Connectors and Plugins

IT admin capabilities: 

• Data export and GitHub Copilot AI Credits

User capabilities

More control for effort level and cost in Cowork

Users can now choose an effort level to control how Cowork balances quality, speed, and credit usage. Medium is the default for everyday work, while Light is designed for simpler tasks. High, Extra High, and Max give Cowork more room for deeper analysis, complex reasoning, and more thorough responses, but may take longer and use limits faster. Model and effort controls now appear directly in the compose box together. This feature rolled out in August.

The /cost skill now provides more visibility into Cowork credit usage. In addition to estimating the credits used for the current task session, it now shows the percentage of the monthly credit limit remaining, credits used month to date, and when the monthly limit resets. This feature rolled out in August.

The Scheduled tab in Cowork is now called Automations. The updated section gives users one place to view and manage all of their automated tasks, including both scheduled and event-triggered tasks. This feature rolled out in August.

Text selections, session sharing, and more for Copilot Chat

Now in Copilot users can select a sentence, paragraph, or table in a Chat response and ask Copilot to work only on that content. The selected text is previewed in the prompt before sending, enabling more focused explanations, summaries, translations, and next steps. This feature rolled out in August.

Copilot users can now share either a full chat session or an individual response through a simple link. Recipients get a read-only view and can continue the chat like it was their own, so they can easily reuse work and collaborate within organizational controls. Users can share their full chat session by selecting ’Share chat’ from the Share menu located in the top right of the chat UX. Or they can share an individual response by selecting ’Share response’ from the More options menu at the end of a response. This feature rolled out in August.

Copilot can now reason over enterprise data from Power BI reports and semantic models in both Chat and Cowork. Users can ask natural-language questions and receive accurate, grounded answers directly from data they have access to. This feature rolled out to Public Preview in June and rolled out worldwide in August.

 

New model-driven answer cards dynamically display content in Chat like weather, sports, finance, images, video, places, and news. The cards surface rich answers for Entra and Microsoft account users based on the user prompt across supported experiences in Copilot. This feature rolled out in August.

Users can now generate a new response to their latest prompt in Chat without having to start over. They can select ‘Try again’ to generate a new response with the same model or they can select a new model and have Copilot run the same prompt. This lets users explore different answers and refine output quality without restarting their conversations. This feature rolled out in August.  

Mobile users can now turn an idea into a ready-to-send email. They simply describe the message they need, and Copilot will create an embedded Outlook draft directly in Copilot Chat. Users can then open the draft directly in Outlook mobile to edit and send. This seamless experience helps users move from idea to action without leaving their flow of work. This feature rolled out in August.

 

New ways to work in Copilot Notebooks

Copilot Notebooks now gives users two connected ways to work: a lightweight experience in the Copilot app, and a workspace experience in OneNote. In the Copilot app, users can quickly chat with Copilot, explore references, and create artifacts. In OneNote, users will get a workspace experience for deeper project work, expanded artifact creation, and team collaboration. Because notebooks stay in sync across the Copilot app and OneNote, users can move between the two without losing context. To go directly from the Copilot app to OneNote, users simply select “Open in OneNote.” This feature rolled out in August.

Copilot Notebooks proactively let users easily generate relevant documents by recommending artifacts based on WorkIQ and their notebook content. Selecting a suggestion prompts Copilot to generate a more specific Word, Excel, or PowerPoint artifact based on the user’s notebook content and current project. This feature rolled out in August.

Multimodal capture on Android helps users bring conversations, meetings, brainstorms, and other work moments into Copilot Notebooks. Users can capture audio, images, and notes in one experience, and Copilot automatically generates structured notes for their Copilot Notebooks. Multimodal capture is also available in the OneNote app on iOS and iPad. This feature rolls out in September.

 

Change languages for meeting recaps with Copilot in Teams

Users can now change the language of a meeting recap after it has been generated. A translation button makes multilingual recaps more flexible when users need the recap in a different language. This feature rolled out in August.

Hyperlinks, image understanding, and highlights for Copilot in Word

Creating polished documents is now easier with Copilot. Users can simply ask Copilot to add hyperlinks, and it can insert and format linked text directly in their document, helping them create professional, connected content without manual editing. This feature rolled out in August.

Copilot can now understand images in a user’s reference documents and incorporate them into the content it creates. Whether users are drafting a new document or building on existing materials, Copilot can use relevant text and visuals from referenced files to help create more complete documents. This feature rolled out in August.

 

When Copilot rewrites or refines text, it now highlights the exact words it edited rather than marking entire paragraph. This more granular view makes it easier for users to review, understand, and accept changes with confidence. This feature rolls out worldwide in August.

New Copilot in PowerPoint capabilities for further brand curation and faster collaboration

Now users can assign tasks and notify relevant stakeholders in comments using Copilot in PowerPoint. Users can ask Copilot to pull in stakeholders and automatically assign follow-ups directly in the comment thread. This helps teams move from feedback to action faster, keeps presentation reviews organized, and reduces the manual effort needed to track next steps across stakeholders. This feature rolled out in August.

Strict brand adherence restricts Copilot to your approved template and slide master layouts. When it's on, Copilot won't add or remove placeholders or invent new layouts. Use it when brand consistency matters more than creative flexibility—for official, customer-facing, or regulated presentations. This feature rolled out in August.

Note steering lets you guide Copilot with plain-language instructions written in a slide's notes for slide by slide governance. Copilot reads those notes each time it creates a presentation from your template, so you don't have to repeat the same preferences in every prompt. Learn more here Manage template settings in your Brand Kit for Copilot in PowerPoint | Microsoft Support This feature rolled out in August.

 

Users can now upload, create, edit and delete their own custom skills in PowerPoint. Skills turn repeated instructions into reusable guidance that Copilot can apply in the flow of a user’s presentation work. To learn more, visit Use custom skills with Copilot in PowerPoint. This feature rolled out in August.

 

Translation capabilities in PowerPoint have now been moved from the ribbon to Copilot in PowerPoint. Translation is now faster, with the ability to dynamically resize text boxes depending on the text. This feature rolled out in August.

 

Copilot can now edit smart art while staying on brand. Use copilot to edit diagrams and shapes on the canvas instead of manually adding and aligning smart art. This feature is in Frontier in August.

Chat history and change history skill for Copilot in Excel

Change history skill helps users understand how a workbook has evolved over time. Copilot can summarize recent changes, identify who made edits, and explain how both people and AI have modified the workbook. It can also help undo specific edits or restore formulas by returning the workbook to a previous working state. This feature rolled out in August.

 

Chat history helps users pick up where they left off with Copilot by preserving past conversations and sessions. To access chat history, use the menu icon in the upper left corner of the Copilot in Excel pane to open your previous conversations. Conversations are listed based on recency, with your most recent chat at the top of the list. Select a conversation from the list to view it. This feature rolled out in August.

Personal skills in Copilot in SharePoint

Users can create personal skills in Copilot in SharePoint and use them across SharePoint sites and OneDrive. Each user-owned skill is saved as a markdown file in OneDrive, so users don’t need to recreate skills for every site. This feature rolled out to Public Preview in August and rolls out worldwide in December.

Agents, email drafting, and management enhancements for Copilot in Outlook

Custom engine agents are now available directly in Outlook. Users can access these agents where they manage their work, making their capabilities available within the Outlook experience. This feature rolled out in August.

 

Copilot in Outlook can help users manage more email and calendar tasks using natural language. Users can ask Copilot to organize messages, apply categories, create folders, manage inbox rules, and take action on meetings and events—all from chat. By bringing more Outlook actions directly into the chat experience, Copilot helps them stay in flow and get work done more efficiently. This feature rolled out in August. 

Improved file capabilities with Copilot in OneDrive

With improved Copilot file capabilities in OneDrive, users can go from files to finished work directly from chat. Copilot helps users find the right content, analyze files and data, create polished outputs like summaries, dashboards, and presentations, and collaborate by saving or sharing the results from OneDrive. This feature rolled out to Public Preview in August and rolls out worldwide in December.

Status reports and task enhancements for Copilot in Planner

Planner Agent can help turn plan data into a polished status report covering progress, risks, overall status, and next steps. Users can specify the audience, tone, length, and sections to quickly produce a stakeholder-ready update. This feature rolled out to Frontier in August.

Copilot will now support creating Planner tasks and querying Planner task information. This lets users manage task work across Copilot and Planner more seamlessly. This feature rolls out in September.

New Connectors and Plugins

Microsoft continues to grow the Microsoft Copilot ecosystem with new connectors and plugins spanning multiple industries. By connecting Copilot to valuable business data and domain-specific knowledge, organizations can unlock richer context, deeper insights, and more relevant experiences across everyday workflows. These include:

• Financial Services: Mercury, Xero
• Legal Services: iManage Work, Boardwise, Harvey, Descrybe Legal Engine, Relativity, Everlaw
• Professional and Business Services: Statista, Crossbeam, ZoomInfo, IDC
• Energy & Resources: S&P Global Energy
• Healthcare & Life Sciences: Scite and Consensus
• Software & Technology: Adobe Journey Optimizer, GoDaddy, Asana

IT admin capabilities

Data export and GitHub Copilot AI Credits

Admins can create custom reports with new data export capabilities from the Copilot and Agent 365 Dashboards. These dashboards now support exporting de-identified, row-level metrics and attributes. Admins can get deeper insights into organizational Copilot and agent usage and user-level interactions while removing personal identifiers. These features roll out in September. 

The Consumption Dashboard in Insights now supports GitHub Copilot AI Credit usage. Admins can analyze how developers use GitHub Copilot to manage adoption and credits. Managers, Insights analysts, and Global admins can compare spending with budgets and make data-driven decisions about GitHub Copilot investment. This feature rolled out in July.

Did you know? The AI at Work Roadmap is where you can get the latest updates on productivity apps and intelligent cloud services. Microsoft Copilot release notes is where you can see the Microsoft Copilot features that are generally available (Current Channel for Microsoft 365 apps) and specific to each platform. Check back regularly to see what features are in development, coming soon and generally available. Please note that the dates mentioned in this article are tentative and subject to change.

Admins often move between multiple areas of the Microsoft 365 admin center to manage their deployment journey. We understand they want a simpler, more connected experience—and their feedback is now coming to life. Starting today, Microsoft is rolling out a new Setup experience that brings these deployment capabilities together in one place where admins can easily track deployment progress, access guides and support, action recommended next steps including direct product configuration, without navigating across multiple pages. 

Here’s a closer look at what’s new in Setup and what’s ahead.

What's new in Setup

Rather than organizing the experience around individual tools or guides, the redesigned dashboard focuses admins on outcomes. It shows where deployment stands and surfaces the most relevant next steps. Deployment progress, onboarding completion, licensing information, and readiness insights appear together, providing a holistic view across Microsoft 365 workloads.

Please select images for expanded hi-res view. 

The redesigned dashboard in the Microsoft 365 admin center.View licensing information for your organization.

Setup goes beyond visibility by using your organization’s deployment status and activity to deliver tailored recommendations in real time. By highlighting the most relevant setup tasks and deployment guidance, it enables admins to spend less time searching and more time taking action. From within the experience, admins can configure products, explore guidance across Microsoft 365 solution areas, and start or resume a deployment guide directly from Setup.

Example of personalized next steps.

The redesigned experience also brings support closer to where deployment work happens. Admins can access training, migration resources, organizational messaging, deployment assistance, and FastTrack support, while dedicated pages provide deeper insights into onboarding health and related activities.

Together, these changes create an integrated self-service experience that gives admins greater visibility into progress, clearer next steps, and easier access to the resources they need to move forward with confidence.

View of dedicated support options.

Looking ahead

The new Setup experience represents an important step toward making Microsoft 365 deployments simpler, more personalized, and easier to navigate. As Microsoft continues learning from admins, their feedback will shape future capabilities—including AI insights and assistance—that make deployment more intuitive, efficient, and responsive to each organization’s needs.

Ready to get started? Sign in to the Microsoft 365 admin center and select Setup to view your organization's deployment progress, personalized guidance, and support options in one dashboard.