Microsoft will deliver two long-awaited SharePoint Framework (SPFx) capabilities in September 2026: Navigation Customizers that can override site navigation, and the general availability of an open-source command-line interface (CLI) to replace the Yeoman generator. But conflicting version numbers in official roadmaps—Microsoft Learn points to SPFx 1.25, while a late July analysis suggests the GA scope may land in SPFx 1.24—have left teams uncertain about what to expect and how to plan. This guide breaks down the features, explains the practical impact for developers and administrators, and offers a concrete checklist to get ready without overcommitting.

What’s Coming in September 2026? The SPFx Update at a Glance

Microsoft Learn’s SPFx roadmap, last updated June 1, outlines a three-stage release cadence leading to September. Version 1.23 shipped on May 13 with a preview of the new CLI, list and library command set improvements, and the open-sourcing of solution templates on GitHub. Version 1.23.1 followed in June, adding panel overrides for lists. A June release of version 1.24 brought an undisclosed “Feature X” to public preview.

The September milestone, originally tagged as version 1.25, includes two headline items: Navigation Customizers, described as “options to override navigation nodes and/or experiences with SPFx components,” and general availability of the SPFx CLI. However, a July WindowsForum roadmap analysis indicates Microsoft has shifted the September GA scope to SPFx 1.24, making the exact version number an open question. For planning purposes, what matters are the capabilities—not the package label—and both features are confirmed for that timeframe.

Navigation Customizers represent the most visible change in the September release. Instead of being limited to SharePoint’s structural navigation, menus, or hub settings, developers will be able to inject SPFx components that replace or augment navigation nodes and the user experience around them.

For organizations with complex intranets—sites that serve multiple audiences, require dynamic content entry points, or depend on custom navigation patterns—this is a strategic capability. An SPFx component could, for example, surface personalized links based on user profile data, integrate with a third-party information architecture, or enforce governance policies at the navigation level.

With that power comes a critical governance question. Navigation is a shared interface; any change to it can affect how employees find information, how site owners manage their structures, and how support teams troubleshoot “missing” links. Before turning this feature on, IT and development leads must define clear boundaries: Which users or roles can deploy navigation overrides? What happens when a customizer is retired or breaks? How do you roll back? These are not just developer concerns—they are tenant-wide change management decisions.

The SPFx CLI: The End of Yeoman?

For years, scaffolding a new SPFx project meant reaching for the Yeoman generator. The new open-source CLI, previewed in version 1.23 and slated for GA in September, fundamentally changes that workflow.

Microsoft has been explicit about two things: the CLI is decoupled from SPFx release versions, and it is designed to support organization-specific templates. That means a team can build a standard project baseline once—complete with naming conventions, folder structures, internal coding standards, and package defaults—and then reuse it consistently. No more relying on tribal knowledge or manual generator choices.

The CLI decision should not be forced as part of a broader September migration. Because the tool is version-independent, you can adopt it for new projects while leaving all existing solutions untouched. The pilot question is straightforward: can your developers reproduce the same approved starting structure every time? If yes, the CLI becomes the preferred path for greenfield work. If not, you keep Yeoman in place and revisit later.

Don’t Confuse Toolchain with Features: The Heft Factor

A hidden variable in any September preparation is the build toolchain. SPFx 1.22 introduced the Heft-based toolchain, while all versions up to 1.21.1 used Gulp. If your team has not yet migrated a solution to Heft, testing Navigation Customizers or the CLI on a legacy Gulp project will muddy the results: failures could stem from toolchain incompatibility, not from the new features.

This matters especially for administrators and engineering managers. A September feature target can encourage an all-at-once push: migrate the toolchain, adopt a new generator replacement, introduce navigation overrides, and revise governance simultaneously. That approach multiplies failure points and makes post-pilot conclusions nearly impossible to interpret. Instead, separate the Heft migration from the feature evaluation. Identify critical, customized Gulp pipelines that need deliberate transition work, and run your Navigation Customizer and CLI tests on projects where the toolchain is already understood.

What This Means for You: Developers vs. IT Admins

For SharePoint Developers

  • Start with the CLI preview now. Grab the preview version in SPFx 1.23 and scaffold a standard project. Document whether you can reproduce your team’s ideal template without manual tweaks.
  • Test Heft on one non-critical solution if you haven’t already. Understand the migration steps and pain points before September pressure mounts.
  • Explore Navigation Customizers in a development tenant. Build a simple override for a test site; experiment with node replacement and experience changes. This will give you a head start on the governance conversations that must follow.

For IT Administrators and Governance Teams

  • Inventory your tenant’s SPFx solutions and their toolchains. Know which are still on Gulp and which moved to Heft. This inventory will inform realistic timelines.
  • Begin a governance draft for navigation customization. Decide approval workflows, ownership boundaries, and emergency rollback procedures. Do not wait until a developer deploys a customizer to the corporate intranet.
  • Separate the decisions. The CLI adoption, Navigation Customizer permissioning, and Heft migration timelines are independent. Do not link them into a single all-or-nothing program.

How to Prepare Without Overcommitting

A pragmatic path forward uses pilots, not mandates. Follow these concrete steps over the next two months:

  1. Pick one existing intranet where navigation is business-critical and user feedback frequently points to navigation problems. This becomes your testbed for Navigation Customizers.
  2. Pick one new, standardized greenfield project to evaluate the CLI. Use a conventional team site or a new intranet section with clear ownership.
  3. Keep the two workstreams separate in reporting, source control, and approval gates. A successful CLI scaffold does not prove navigation customization is safe, and vice versa.
  4. Record the SPFx version, toolchain, and project template used in every test. With the release version still unsettled, that metadata is essential for post-pilot decisions.
  5. Set a governance checkpoint after the pilots. Decide: should Navigation Customizers be permitted broadly, limited to centrally managed intranets, or held for further evaluation? Should the CLI become the default for new projects? Make these decisions independently.

Throughout, treat September as a checkpoint, not a deadline for every repository. The capabilities are coming, but the exact version number may shift. Your pilot results—not Microsoft’s release label—should drive your rollout.

The Bottom Line

Microsoft’s September 2026 SPFx update is genuinely significant: Navigation Customizers open a new extension point that can reshape the intranet experience, and the CLI modernizes a development workflow that has felt dated for years. But the version confusion between 1.24 and 1.25 is a reminder that roadmaps can change. Rather than rushing into a tenant-wide upgrade, use the summer to gather evidence on both features in controlled settings. By the time September arrives, you will have clear, independent answers on whether to adopt navigation overrides for your critical portals and whether to standardize on the new CLI for all new projects—without betting your go-live on an unconfirmed version number.