#sharepoint

SharePoint Designer End of Support July 2026: What to Migrate To

SharePoint Designer 2013 extended support ends July 14, 2026. Here's how every SPD feature maps to its modern equivalent in Power Automate, SPFx, and SharePoint Online — with a practical migration checklist.

by Mattia Musazzi
SharePoint Designer end of support 2026: what replaces it in Microsoft 365

In brief

  • SharePoint Designer 2013 extended support ends July 14, 2026 — confirmed by Microsoft’s official Product Lifecycle page
  • SPD is replaced by three tools: Power Automate (workflows), SharePoint Framework/SPFx (custom development), and Power Apps (custom forms)
  • SharePoint now has over 1 billion active users (Microsoft M365 Conference, May 2025) — and Power Automate runs 2 billion flows per week through SharePoint alone
  • If you still have SPD 2010-style workflows running in your tenant, they stopped working for new tenants from 2020 — SPD 2013 workflows are what need migration now
  • The migration path is well-documented; most SPD workflow patterns have direct Power Automate equivalents built into templates

SharePoint Designer 2013 reaches end of support this month

Microsoft’s extended support for SharePoint Designer 2013 ends on July 14, 2026 (Microsoft Lifecycle). Mainstream support ended on July 13, 2021 — so the tool has been in extended (security-only) support for the past five years. After July 14, no further security patches will be issued.

The application itself won’t stop running overnight. But organizations still using SPD for production workflows face three real risks after the deadline: unpatched security vulnerabilities, increasing incompatibility with SharePoint Online updates that Microsoft can ship without constraint from legacy SPD compatibility, and audit findings when compliance frameworks require that software within scope receives vendor security updates.

If your organization still runs SharePoint Designer workflows, the migration window is now.


What SharePoint Designer was

SharePoint Designer was Microsoft’s free tool for customizing SharePoint sites and building workflow automation. Released in various versions from 2007 through its final version in 2013, it served as the primary way to:

  • Build automated workflows without writing server-side code (approvals, notifications, data updates)
  • Customize site layout through master pages, page layouts, and CSS sheets
  • Create custom list forms and data views using XSLT
  • Manage site navigation, content types, and site columns

It was widely used because it bridged the gap between SharePoint’s out-of-the-box features and what organizations actually needed — without requiring a developer for every change. At its peak, tens of thousands of organizations ran business-critical processes on SPD workflows.

The problem is that SPD was built for SharePoint Server’s “Classic Experience” architecture. When Microsoft introduced SharePoint Online’s Modern Experience starting in 2016, SPD’s model — direct page editing, master pages, XSLT — no longer fit. Most SPD features either don’t work with modern SharePoint pages or produce results that break the modern interface.

For a broader overview of what SharePoint Online can do today, see our guide on Microsoft SharePoint.


What replaces SharePoint Designer: the migration map

Every core SPD capability has a modern replacement. Here’s how they map:

SharePoint Designer featureModern replacement
List workflows, site workflowsPower Automate cloud flows
Reusable workflowsPower Automate solution flows
Custom list formsPower Apps canvas apps
Data View Web Part (XSLT)Power Apps, SharePoint list views
Master pagesSharePoint Online theme builder + SPFx
Page layoutsModern page templates + SPFx
CSS customizationSharePoint brand center, SPFx
InfoPath integrationPower Apps

Migrating SPD workflows to Power Automate

This is the migration that matters most for most organizations. SPD workflows fall into three categories: List Workflows, Reusable Workflows, and Site Workflows. All three map to Power Automate cloud flows, though the approach differs slightly.

List workflows are the most common. They trigger when items are added or modified in a specific SharePoint list. In Power Automate, these become flows with a “When an item is created” or “When an item is modified” trigger — the same logic applies. The primary difference is that Power Automate adds conditions and actions through a visual drag-and-drop interface and connects to 1,000+ services beyond SharePoint, not just the local tenant.

Reusable workflows in SPD could be applied to any list with a matching content type. In Power Automate, the equivalent is a flow stored in a solution — portable, environment-aware, and deployable across sites without rebuilding from scratch.

Site workflows run on demand against the entire site rather than a list. In Power Automate, these become instant flows that a user or administrator can trigger manually from the SharePoint site or via a button.

Power Automate includes built-in SharePoint templates that cover the most common SPD patterns: document approval flows, item notification emails, status change updates, and scheduled list operations. Starting from a template rather than from blank is the fastest migration path for most workflows.

For a deeper look at what Power Automate can do, see our Power Automate guide.

Sharepoint designer vs power automate Building a SharePoint workflow in Power Automate with Copilot assistance

According to Jeff Teper, Corporate VP at Microsoft, Power Automate runs over 2 billion flows per week through SharePoint alone as of May 2025 (vladtalkstech.com, 2025). The migration from SPD to Power Automate is well-trodden at this point — the tooling, templates, and organizational knowledge are mature.


Migrating forms and data views to Power Apps

SharePoint Designer allowed customization of list forms through InfoPath integration and custom XSLT data views. Both are replaced by Power Apps.

A Power Apps canvas app embedded in a SharePoint list replaces a custom SPD form in most cases. The canvas app can read and write to the SharePoint list, enforce conditional visibility rules, validate input before submission, and trigger Power Automate flows on save. Building the equivalent of most SPD forms takes a few hours rather than days, and the result works on mobile browsers without any additional configuration.

For data views — XSLT-driven table renderings of list data — SharePoint’s built-in list views with filtering, grouping, and conditional formatting now cover most scenarios that previously required a Data View Web Part. When that’s not enough, Power Apps can render SharePoint list data in custom layouts with full sorting and filter control.

Sharepoint designer vs microsoft forms Collecting structured data with Microsoft Forms connected to SharePoint


Migrating site branding and layout to SPFx and SharePoint Online

SPD’s branding tools — master pages, page layouts, CSS sheets — targeted SharePoint’s Classic Experience. The Modern Experience uses a fundamentally different rendering architecture where master pages don’t exist.

For organizations that need custom branding beyond what SharePoint’s built-in theme builder and brand center provide, SharePoint Framework (SPFx) is the replacement. SPFx extensions can inject custom headers, footers, navigation, and scripts across an entire site collection without touching the Classic Experience infrastructure. SPFx web parts replace custom web parts built with SPD’s older extension model.

The practical threshold: if your SPD branding work was mostly applying corporate colors and logo placement, the SharePoint Online theme builder and brand center handle this without any code. If it involved complex layout structures or custom navigation behaviors, SPFx is the path forward.

Sharepoint designer vs microsoft teams SharePoint content pinned directly in Microsoft Teams tabs


SharePoint Designer vs. SharePoint Online Modern Experience: key differences

The shift from SPD to SharePoint Online’s Modern Experience is more than a tool swap — it’s a different design philosophy.

SPD assumed a developer or power user would directly edit page HTML, CSS, and XSLT. That flexibility was powerful, but it came with significant maintenance overhead. Every update to SharePoint risked breaking customizations that touched the Classic Experience rendering pipeline. Organizations built up layers of fragile customization that required dedicated SharePoint developers to maintain.

SharePoint Online’s Modern Experience takes the opposite approach. No-code customization through the page editor is the default path. Professional development (SPFx) uses a supported, versioned extension model that Microsoft tests against SharePoint updates before they roll out. The result is more predictable: less custom breakage, lower maintenance costs, and a much wider pool of users who can maintain content without developer involvement.

The tradeoff is less granular control at the HTML level. Organizations that relied on deep XSLT customizations or direct DOM manipulation through SPD will find SPFx requires more upfront development effort than SPD did. But that investment produces solutions that stay functional through SharePoint Online updates, something SPD customizations increasingly couldn’t guarantee.

For a complete guide to building a SharePoint-based intranet today, see our SharePoint intranet guide.


7 best practices for modern SharePoint development (post-SPD)

1. Audit your SPD workflows before the deadline

Before July 14, inventory every SPD workflow still running in your tenant. The SharePoint admin center shows active workflows in the Workflows section. Prioritize: which workflows run daily vs. occasionally? Which are business-critical? Start migration with the high-frequency, high-impact ones.

2. Use Power Automate solution flows for portability

Don’t build flows in the default environment. Create solution flows from the start — they’re portable across environments, version-controlled, and easier to manage at scale. This is especially important if you have multiple SharePoint sites with similar workflow needs.

3. SPFx for development, built-in tools for content

Keep the division clear: SPFx for code-driven customization (web parts, extensions, custom navigation), SharePoint’s built-in tools for content and layout. Mixing both without a clear boundary creates the same maintenance complexity SPD created.

4. Mobile-first for modern pages

SharePoint Online’s Modern Experience is responsive by default. SPFx solutions should be tested on mobile before deployment — not as an afterthought. The page editor’s column layouts and built-in web parts are all mobile-optimized; custom SPFx components need to match that baseline.

5. Use SharePoint templates for new sites

Rather than building from blank and customizing, start from SharePoint’s site templates (communication site, team site, project site). They embed current best practices for information architecture and save setup time significantly.

Sharepoint templates showcase

6. Governance: metadata over folders

SPD often enabled folder-heavy information architectures because XSLT views made them functional. Modern SharePoint works better with flat libraries and metadata columns — the built-in filter pane and metadata navigation are more powerful than nested folders and easier to maintain. Migrating away from deep folder structures during an SPD migration is worth the extra effort.

7. Monitor with SharePoint Usage Analytics

After migration, monitor with SharePoint Usage Analytics in the Microsoft 365 Admin Center. Track which pages and files see the most traffic, whether workflows are completing as expected, and whether Power Automate flows are running without errors. Usage patterns often reveal which migrated workflows actually matter and which can be simplified or retired.

Sharepoint analytics SharePoint analytics dashboard in the Microsoft 365 Admin Center


FAQ

When does SharePoint Designer 2013 reach end of support? SharePoint Designer 2013 extended support ends on July 14, 2026, per Microsoft’s official Product Lifecycle page. Mainstream support already ended on July 13, 2021. After July 14, no further security patches will be issued. The application won’t stop working that day, but organizations running it in production should complete their migration before the deadline.

What replaces SharePoint Designer for workflow automation? Power Automate is the direct replacement for SPD workflows. It covers list workflows, reusable workflows, and site workflows through cloud flows with SharePoint triggers. It also connects to 1,000+ services beyond SharePoint. As of May 2025, Power Automate runs over 2 billion flows per week through SharePoint alone.

Can I still use SharePoint Designer after July 14, 2026? Technically yes — the application won’t stop running. But after the support end date, Microsoft won’t issue security patches, creating compliance and security risk. Most frameworks that require software to receive vendor security updates (SOC 2, ISO 27001, NIS2) would flag this during audits.

What replaced SharePoint Designer for custom forms? Power Apps replaces SPD’s custom form capability. You can embed a Power Apps canvas app in any SharePoint list to replace a custom list form. Power Apps supports conditional logic, rich validation, and integration with other Microsoft 365 services — more capable than SPD’s InfoPath-based forms.

What replaced SharePoint Designer for site customization? SharePoint Framework (SPFx) handles code-level customization: custom web parts, header/footer extensions, navigation customizations. For no-code branding, SharePoint Online’s theme builder and brand center cover logo placement, color palettes, and font choices without any development work.

Is SharePoint Designer still available to download? SPD 2013 was removed from the Microsoft Download Center. Installation files circulate on third-party sites, but installing it on modern systems is not recommended given the end-of-support date and limited SharePoint Online compatibility — particularly with Modern Experience pages.

How long does migrating SPD workflows to Power Automate take? It depends on workflow complexity. Simple single-step notification flows migrate in 30-60 minutes. Complex multi-stage approval workflows with branching conditions typically take 4-8 hours each. Most organizations with dozens of SPD workflows complete the migration in 2-6 weeks with a dedicated effort.

Mattia Musazzi

Written by

Mattia Musazzi

Modern Work · Dev4Side

Dev4Side Software · Microsoft Gold Partner

Need help implementing this in your company?

Our specialist teams have delivered 200+ Microsoft implementations across Italy. Contact us for a free, no-obligation evaluation of your project.