Classic SharePoint to Modern SharePoint

Direct answer: Moving from Classic SharePoint to Modern SharePoint is not a page conversion exercise. Legacy environments carry publishing sites, custom master pages, page layouts, Script Editor and Content Editor Web Parts, JSLink, custom JavaScript and CSS, SharePoint Designer workflows, InfoPath forms, legacy web parts, search customizations, custom APIs, add-ins, farm and sandbox-era solutions, and third-party integrations — each needing a retire, retain, replace, modernize, or rebuild decision driven by business requirements.

Modernization is a business-requirement decision, not a one-to-one technology replacement exercise. Some components retire, some have native modern alternatives, some need Power Platform, some require SPFx, and some require architectural redesign.

1. Classic SharePoint — pages, scripts, workflows, forms, customizations as found.
2. Discover — find every legacy dependency, not just pages.
3. Inventory — record what, where, owner, usage, and dependencies.
4. Assess — requirement, supportability, and risk per component.
5. Retire, retain, replace, modernize, or rebuild — decided per component.
6. Modern SharePoint — with SPFx, Power Platform, and Microsoft Graph where justified.

Microsoft's own phased changes to classic experiences carry specific timelines — see the modernization roadmap for the current dates rather than any date stated here. For the surrounding program, use Migration Assessment & Readiness, the Migration Checklist, Migration Validation, and the migration hub.

Print Modernization Checklist

Classic versus modern SharePoint

Classic is not automatically bad — legacy implementations often encode important business logic that must be understood before replacement. Compare honestly, area by area:

Why inventory comes first

Do not start with "how do we convert this?" Start with "what business requirement does this still satisfy?" Technical inventories alone are insufficient — an inventory without owners, usage, and requirements is a parts list, not a plan. For every legacy component capture what it is, where it lives, who owns it, who uses it, what business requirement it satisfies, what data it accesses, what else depends on it, whether it is still required, and what happens if it disappears.

1. Legacy component — as found.
2. Business requirement — in the owner's words, not the code's.
3. Still required? — no requirement ends the discussion.
4. Modern capability available? — native, Power Platform, or SPFx.
5. Decision — retire, retain, replace, modernize, or rebuild.

Modernization decision framework

Five decisions cover every component. Actual decisions always require environment-specific analysis — the framework keeps them consistent, not automatic:

1. Legacy component — inventoried with its requirement.
2. Still used? — no goes to retire.
3. Native modern capability? — yes goes to replace.
4. Can the requirement be redesigned? — yes goes to modernize.
5. Custom development justified? — yes goes to rebuild, funded and owned.

Classic site inventory

• Site collections inventoried
• Sites and subsites inventoried
• Classic team sites identified
• Publishing sites identified
• Classic pages inventoried
• Publishing pages inventoried
• Page layouts inventoried
• Master pages inventoried
• Web Parts inventoried
• Scripts inventoried
• CSS inventoried
• Workflows inventoried
• Forms inventoried
• Search customizations inventoried
• Navigation inventoried
• Custom solutions inventoried
• APIs inventoried
• Integrations inventoried
• Permissions reviewed
• Content Types reviewed
• Metadata reviewed
• Business owners identified
• Usage reviewed

Risk and readiness depth lives in Migration Assessment & Readiness — this inventory tracks completion, that guide explains what to look for.

Classic pages to modern pages

Assess page type, layout, web parts, embedded scripts, custom branding, business functionality, and publishing dependencies. Simple content pages usually map cleanly to modern pages; pages with custom functionality route to modern capabilities or SPFx; legacy publishing requirements trigger architecture redesign rather than conversion. Not every classic page can or should be treated as a simple visual conversion.

1. Classic page — components analyzed, not just screenshotted.
2. Simple content? — goes to a modern page.
3. Custom functionality? — goes to a modern capability or SPFx.
4. Legacy publishing requirement? — goes to architecture redesign.

Script Editor Web Part

Script Editor implementations earn a major section because they hide arbitrary code behind an innocent page component — and each one is a Migration-to-SPFx decision. Inventory every instance and assess what its scripts actually do: DOM manipulation, SharePoint REST calls, JSOM usage, external APIs, custom UI, navigation, forms, business logic, third-party libraries, hard-coded URLs, embedded credentials or secrets, and authentication assumptions. Then route by function: still required, then native capability, JSON formatting, Power Platform, SPFx, or retire. Never treat Script Editor to SPFx as automatic — most scripts implement presentation or process needs that modern capabilities already cover, and secrets found in scripts trigger a credential-rotation conversation first. For the full per-script decision process, see Script Editor to SPFx modernization.

Content Editor Web Part

Determine what each instance actually contains: static content, HTML, JavaScript, CSS, embedded resources, links, or external content. Static content moves to the modern Text web part; embeds go to the Embed capability where appropriate; functional needs follow the same native, SPFx, or retire routing as Script Editor; anything without a requirement retires. The decision follows functionality, never the web part name.

Custom JavaScript

Inventory script location, loading mechanism, dependencies, DOM assumptions, SharePoint APIs used, authentication, external libraries and APIs, business logic, owners, and usage. Then route by purpose: UI formatting goes to JSON formatting where appropriate, automation to Power Automate where appropriate, business apps to Power Apps where appropriate, genuinely custom client experiences to SPFx where justified, and anything undefended to retire. Depth: Explore SharePoint Framework (SPFx).

JSLink

Legacy JSLink customizations typically rendered list views, fields, or forms with custom JavaScript. Formatting-only needs move to JSON column or view formatting; advanced custom rendering moves to SPFx Field Customizers or other supported architecture. Do not imply JSON formatting reproduces arbitrary JavaScript behavior — it covers presentation rules, not application logic.

Custom master pages

Classic master-page approaches do not transfer to modern SharePoint and should not be recreated. Inventory branding, header, footer, navigation, custom CSS, JavaScript injection, layout changes, and corporate identity requirements — then extract the underlying business requirements into branding, navigation, extensions, and theme decisions. Modern approaches include themes, modern site branding, hub navigation, and SPFx Application Customizers where justified. Never attempt an exact classic master page recreation; modernize the identity, not the artifact.

Custom CSS

Unsupported DOM-level customization breaks silently on Microsoft updates, so assess why each stylesheet exists and what business or UI requirement it addresses. Where modern theming satisfies the need, theme it; where a component is genuinely required, build it properly with SPFx. Do not encourage unsupported global CSS injection as a migration shortcut — it converts a migration project into a maintenance liability.

SharePoint Designer workflows

Inventory each workflow's triggers, actions, conditions, approvals, emails, data sources, external dependencies, owners, and business criticality. Then require the business process to be understood before anything is rebuilt: still required, redesigned around current requirements, implemented in Power Automate or a supported alternative, or retired. Power Automate is a redesign target, not a direct converter — triggers, permissions, connections, and error handling are re-proven per workflow. Patterns: approval workflows, SharePoint trigger patterns, and the Power Automate hub.

InfoPath

Inventory forms, data connections, rules, validation, conditional formatting, code, external services, workflow dependencies, and embedded business logic. Route by requirement: simple forms to modern SharePoint forms, business applications to Power Apps, complex custom experiences to SPFx or another appropriate architecture, and undefended forms to retire. Never position Power Apps as an automatic InfoPath converter — data connections and rules are redesigned, and the Power Apps vs SPFx comparison helps place the complex cases. Dataverse-backed direction: Dataverse vs SharePoint data sources.

Classic web parts

For each legacy web part ask whether a modern equivalent exists, whether the requirement can be redesigned, and whether custom development is still justified:

Directions are possibilities, never fabricated direct replacements — each row still needs its decision.

Legacy SharePoint solutions

For farm solutions, sandbox solutions, legacy add-ins, provider-hosted solutions, custom web parts, custom event logic, and custom APIs, determine business requirement, hosting model, authentication, data and integration dependencies, target compatibility, and modernization approach. Do not assume all legacy custom code should become SPFx — most of it should retire or become platform capability, with SPFx reserved for justified custom development.

SPFx as a modernization option

SPFx fits custom web parts, application extensions, command sets, field customizers, custom enterprise UI, Microsoft Graph integration, SharePoint API integration, external API integration, and Teams-integrated experiences where applicable. Apply architectural judgment in order: business requirement first; native Microsoft 365 capability where it fits; Power Platform where appropriate; SPFx where a custom client-side experience is genuinely required. Depth: Explore SharePoint Framework (SPFx), what SPFx is, how extensions behave.

SPFx modernization architecture

Modernized custom experiences typically compose modern SharePoint with SPFx built on React, PnPjs, Microsoft Graph, SharePoint APIs, and external APIs — secured by Microsoft Entra ID. That implies reviewing authentication, API permissions under least privilege, deployment through the App Catalog, ALM discipline, and environment configuration. Keep this section as orientation; implementation depth lives on the SPFx hub.

Power Automate in modernization

Approvals, notifications, document and list processes, scheduled automation, cross-Microsoft 365 automation, and business workflows are the natural Power Automate territory — reached by redesigning the legacy process, never by blindly rebuilding bad processes in a new engine. Legacy workflow first, business process second, redesign third, Power Automate fourth.

Power Apps in modernization

Custom forms, business applications, mobile experiences, multi-source processes, and Dataverse-backed applications may fit Power Apps — decided per legacy form or application against its requirement, with data-source design from the Dataverse vs SharePoint guide.

JSON formatting

Column and view formatting, conditional presentation, and platform-supported actions remove whole classes of custom code without deployment. Route visual requirements through one question — can JSON formatting handle it? — and only then evaluate SPFx or other approaches. Never claim JSON formatting replaces arbitrary JavaScript; it handles presentation, not logic.

Search modernization

Assess Search Centers, result sources, display templates, query rules, custom search pages, and custom search web parts against current business need, then choose among Microsoft Search, modern SharePoint search, PnP Modern Search where used, custom SPFx search experiences, or other supported designs. No single search solution is universally correct — the requirement and the content estate decide.

Navigation modernization

Assess classic, structural, managed, custom, hard-coded, and master-page navigation, then redesign around hub navigation, modern site navigation, global navigation where applicable, and SPFx extensions where justified. Tie navigation redesign to information architecture work — navigation mirrors structure, so redesigned structures need redesigned navigation. Patterns: the information architecture blueprint.

Information architecture

Modernization is not only UI modernization. Review sites, subsites, hub sites, libraries, folders, metadata, content types, navigation, search, and permissions, then rebuild the hierarchy around business structure into a modern architecture. Never automatically recreate deeply nested legacy structures — flatten into hub-connected sites with metadata-driven libraries.

Permissions during modernization

Architecture changes move permission boundaries: split and consolidated sites, new group-connected workloads, and redesigned libraries all invalidate old access assumptions. Review site permissions, groups, unique permissions, external access, ownership, and identity mapping through the modernization lens, with method depth in SharePoint Migration Permissions. Do not duplicate that guide here — carry its checklist into the modernization plan.

Microsoft Graph in modernized solutions

Users, groups, Teams, files, and Microsoft 365 data reach modernized solutions through Graph called from SPFx, Power Platform, or applications — authenticated under least privilege. Not every SharePoint operation belongs on Graph; SharePoint APIs remain appropriate where they fit. Concepts: Microsoft Graph for beginners and what Microsoft Graph is.

Third-party solutions

For third-party web parts, workflow and forms products, migration-era dependencies, search products, and custom connectors, determine licensing status, support status, continued requirement, modern-version availability, native replaceability, and what happens to existing data and configuration. Evaluate evidence only — never criticize named vendors without it.

Modernization matrix

Modern options are possibilities, never guaranteed one-to-one replacements — each row still records its own decision with an owner.

Modernization prioritization

Prioritize by business criticality, usage, technical complexity, security risk, supportability, migration-blocker status, dependencies, modern-alternative availability, and effort. No numeric scores — use plain priorities:

Modernize before, during, or after migration

There is no universal sequence — the component decides. Migration blockers are addressed before or during migration; business-critical modernization is planned with migration; non-blocking improvements can follow once content stabilizes.

1. Legacy component — assessed with its requirement.
2. Migration blocker? — yes goes before or during migration.
3. Business critical? — yes plans modernization with migration.
4. Otherwise — consider post-migration modernization.

Modernization pilot

Pilot with a representative slice — a classic page, a legacy script, a workflow, a form, permissions, search, an SPFx or custom component, and a business process — then modernize, migrate, validate, user-test, and refine the architecture before scaling. A pilot of only simple pages proves nothing about legacy risk.

Validation after modernization

Validate content, metadata, permissions, pages, navigation, search, workflows, forms, Power Automate, Power Apps, SPFx, Graph and API integrations, and business processes — method depth in SharePoint Migration Validation, not duplicated here.

Modernization risks

Common modernization mistakes

• Migrating everything without inventory — sprawl arrives modernized in name only.
• Rebuilding every legacy customization — most should retire or become platform capability.
• Assuming SPFx is required for everything — it is reserved for justified custom development.
• Assuming Power Apps replaces every form — requirements decide, per form.
• Assuming Power Automate replaces every workflow — redesign first, per process.
• Copying legacy information architecture — flatten into hubs and metadata.
• Ignoring permissions — access failures follow architectural changes.
• Ignoring integrations — silent breakage after content moves.
• Skipping pilot testing — production-shaped risk belongs in the pilot.
• Skipping business validation — tool success is not user success.
• Removing functionality without owner approval — retirement is a signed decision.

Solution blueprint: classic SharePoint modernization

Reference shape only — not a customer case study. Classic pages, scripts, workflows, forms, and customizations pass through discovery and assessment into retire, replace, modernize, and rebuild decisions, landing on SharePoint Online with SPFx, Power Apps, Power Automate, Microsoft Graph, and Microsoft Entra ID where each is justified.

1. Classic SharePoint — pages, scripts, workflows, forms, customizations.
2. Discovery and assessment — inventory, requirements, dependencies, owners.
3. Modernization decisions — retire, replace, modernize, rebuild per component.
4. Modern Microsoft 365 — SharePoint Online plus SPFx, Power Apps, Power Automate, Microsoft Graph, and Microsoft Entra ID.

Modernization checklist

Discover: sites, pages, web parts, scripts, workflows, forms, integrations inventoried; owners identified; usage reviewed.

Assess: business requirements confirmed; dependencies mapped; unsupported approaches identified; migration blockers identified.

Decide: retire, retain, replacement, modernization, and rebuild decisions documented per component.

Design: modern architecture, SPFx requirements, Power Platform requirements, search strategy defined; permission model reviewed.

Implement: pilot completed; migration completed; modern components deployed.

Validate: content, permissions, workflows, forms, SPFx, integrations tested; business users validate critical scenarios.

Modernizing a legacy SharePoint environment?

If you are assessing classic pages, custom scripts, SharePoint Designer workflows, InfoPath, legacy integrations, or SPFx modernization requirements, share the environment and challenge with nextM365: Discuss Your Modernization.

Continue with Explore SharePoint Migration, Explore SPFx, the assessment guide, the migration checklist, migration validation, and modernization roadmap.