Microsoft Build 2026 delivered more news for SharePoint developers than the last three conferences combined. The SharePoint Framework (SPFx) is getting React 18, a completely new build system, its own CLI and a binding quarterly release cadence. This article summarises what is changing, what needs migrating and how Swiss development teams should approach the transition.

React 18 in the SharePoint Framework

The most eagerly awaited change: starting with the version announced for June 2026, SPFx officially supports React 18. This brings Concurrent Features — in particular startTransition, useDeferredValue and the new Suspense rendering model — to SPFx web parts.

Important caveat: Microsoft has explicitly communicated that out-of-the-box web parts (the built-in SharePoint web parts) must be updated to React 18 first before the framework raises the React version tenant-wide to 18. Until then, React 18 in the SPFx context is opt-in: new projects can already use React 18, but solutions running in tenants where not all OOB web parts have been updated may face compatibility issues.

What React 18 actually brings

• Concurrent Rendering: UI updates can be interrupted and prioritised — important for complex SharePoint dashboards with many data sources
• Automatic batching: Multiple setState calls inside promises, timeouts and native events are now automatically batched
• Suspense for data fetching: Data loading can be declared directly in the JSX tree
• useId hook: Stable, server-safe IDs — relevant for accessible forms and ARIA attributes in web parts
• useDeferredValue and startTransition: Smoother filtering and search in list web parts without jank

Migration path from React 17 to React 18

Existing SPFx solutions using ReactDOM.render() must switch to createRoot() from react-dom/client:

// Before (React 17 / SPFx up to 1.19)
import ReactDOM from 'react-dom';
ReactDOM.render(<MyWebPart {...props} />, this.domElement);

// After (React 18 / SPFx 1.20+)
import { createRoot } from 'react-dom/client';
const root = createRoot(this.domElement);
root.render(<MyWebPart {...props} />);

In WebPart.ts the root object must be persisted and explicitly torn down with root.unmount() in onDispose(). Forgetting this creates memory leaks when navigating between pages.

Gulp replaced by Heft and webpack

The old Gulp-based build system has hampered SPFx developers for years: slow builds, hard-to-debug pipeline steps and poor extensibility. With Build 2026, Microsoft makes the switch to Heft (the Rush Stack build orchestrator from Microsoft) and webpack 5 official and default.

Why Heft?

Heft is the build orchestrator Microsoft uses internally for Office and Teams. It is designed for large monorepos, runs tasks in parallel and has a clean plugin model. Key advantages over Gulp:

Migration steps

1. 1Use the SPFx CLI (see next section) — the new spfx upgrade command updates package.json, removes Gulp dependencies and generates heft.json and webpack.config.js
2. 2Delete gulpfile.js — not needed after the upgrade; Heft takes over all tasks
3. 3Port custom Gulp tasks — custom steps must be rewritten as Heft plugins. Simple tasks like SCSS compilation are often already available as standard Heft plugins
4. 4Update CI/CD — pipeline scripts calling gulp bundle --ship or gulp package-solution --ship must switch to heft build --production

Important for existing projects: Microsoft provides an automated migration path; solutions with very specific Gulp customisations (e.g. custom localisation pipelines or SVG sprite generation) require manual porting.

The new SPFx CLI — goodbye Yeoman

Yeoman was a foreign body in the modern JavaScript ecosystem as a scaffolding tool: heavyweight, dependent on many global npm packages and barely maintainable. Microsoft replaces Yeoman with its own open-source SPFx CLI, installed as an npm package:

npm install -g @microsoft/spfx-cli

New commands

# Scaffold a new project
spfx new --template web-part --name MyDashboard

# Upgrade an existing project to the current SPFx version
spfx upgrade

# Package the solution (equivalent to gulp bundle + gulp package-solution --ship)
spfx build --production

# Deploy directly to SharePoint (no manual .sppkg upload)
spfx deploy --site https://contoso.sharepoint.com/sites/dev

# Start the dev server (replaces gulp serve)
spfx serve

The CLI is open-source at github.com/microsoft/spfx-cli and accepts community contributions. For Swiss development teams maintaining their own scaffolding templates, the new CLI offers far simpler extension mechanisms than the old Yeoman generator model.

Quarterly release cadence

With Build 2026, Microsoft announced for the first time a binding quarterly release cadence for SPFx:

• Q1 (January): Stability and security release
• Q2 (April / May): Feature release with preview features from the dev community
• Q3 (July): Mid-year release with bug fixes and performance updates
• Q4 (October / November): Major feature release (such as React 18 this year)

For teams this means: SPFx version jumps every three months instead of irregular ad-hoc releases. Upgrade scripts will be updated after each quarterly release accordingly. For organisations with longer approval processes, it is recommended to plan upgrades around Q1 and Q3 versions (stability releases) and test Q2/Q4 in a dev tenant environment first.

Navigation Customizers

Also in the Build 2026 announcement: Application Customizers can now be extended to Navigation Customizers — a long-requested feature. Navigation Customizers allow the SharePoint main navigation, hub navigation and footer navigation to be fully replaced with custom React components, without SPFx tenant overrides or PnP hacks.

Use cases

• Company-wide, brand-consistent navigation without the SharePoint standard UI
• Dynamic navigation based on Entra ID groups (e.g. different menus for HR, IT and management)
• Integration of search and AI assistants directly into the navigation (e.g. Microsoft Copilot sidebar)
• Multilingual navigation for Swiss companies with DE/FR/IT requirements

// Minimal Navigation Customizer example
import { BaseApplicationCustomizer, PlaceholderName } from '@microsoft/sp-application-base';
import { createRoot } from 'react-dom/client';

export default class NavCustomizerApplicationCustomizer extends BaseApplicationCustomizer {
  public onInit(): Promise<void> {
    const topNav = this.context.placeholderProvider.tryCreateContent(
      PlaceholderName.Top
    );
    if (topNav) {
      const root = createRoot(topNav.domElement);
      root.render(<CompanyNavigation context={this.context} />);
    }
    return Promise.resolve();
  }
}

Migration checklist for Swiss development teams

Immediately (before the tenant upgrade to SPFx 1.20)

• Install SPFx CLI: npm install -g @microsoft/spfx-cli
• Analyse all existing solutions with spfx upgrade --dry-run
• Upgrade a dev tenant to SPFx 1.20 and test solutions

Short term (next 4–8 weeks)

• Migrate ReactDOM.render() to createRoot() in all web parts
• Update onDispose() in all web parts to call root.unmount()
• Replace Gulp pipeline with Heft (spfx upgrade handles most of it automatically)
• Switch CI/CD from gulp bundle --ship to heft build --production
• Port custom Gulp tasks as Heft plugins

Medium term (Q3 2026)

• Evaluate Concurrent Rendering optimisations (startTransition, useDeferredValue) in data-heavy web parts
• Introduce Navigation Customizers for company-wide navigation
• Migrate scaffolding templates from Yeoman to SPFx CLI

Conclusion

Build 2026 turns SPFx into a first-class, modern development framework: React 18, a professional build system and a dedicated CLI are steps many developers have been calling for for years. The quarterly cadence provides planning certainty.

For Swiss development teams the message is clear: now is the right time to inventory existing SPFx solutions, work through the migration checklist and start dev tenant testing — before Microsoft rolls out the Q4 update to production tenants.

CNEXT supports SharePoint development projects in Switzerland — from solution architecture to migration to current SPFx versions.