Share via

Migration from SharePoint 2019 OnPrem to SPSE

Shivam 0 Reputation points
2026-03-25T11:46:56.54+00:00

Hi,

Environment: SharePoint 2019 on prem.

I have an asp.net webform app PHA with High Trust. connected with SharePoint PWA.

There we are using Resources, and projects, and we do have some .wsp packages, RemoteEventReceivers.

now we are planning to migrate this application to SPSE.

Can anyone guide here with planning and Risks?

whether all these will work there or not? or need some customization?

anyone has done that?

Looking for the help and answers.

Microsoft 365 and Office | SharePoint | Development
0 comments
Answer accepted by question author
  1. Steven-N 22,485 Reputation points Microsoft External Staff Moderator
    2026-03-25T13:14:19.5666667+00:00

    Hi Shivam

    Thank you for reaching out to Microsoft Q&A forum

    From my research, the recommended approach is to perform a database‑attach upgrade by deploying a new SPSE farm and attaching the SharePoint 2019 content databases, including the Project Web App database. Project Server is fully supported in SPSE (Enterprise edition only), and PWA data such as projects and resources are upgraded as part of this process. After attaching the databases, you should run Test‑SPContentDatabase to identify any missing or uninstalled custom components.

    For the individual components:

    Provider‑hosted add‑in (High Trust): High‑trust provider‑hosted add‑ins are still supported in SPSE. However, the trust configuration must be recreated on the new farm. This includes re‑registering the certificate and trusted token issuer, and ensuring that the App Management Service and App Catalog are properly configured.

    Farm solutions (.wsp): Farm solutions that are working in SharePoint 2019 are generally supported in SPSE and, in most cases, can be redeployed without recompilation. It is recommended to review these solutions to ensure they do not rely on APIs or features that are deprecated or removed in SPSE.

    Remote Event Receivers: Remote Event Receivers remain supported in SharePoint Server on‑premises, including SPSE. You should ensure that the remote endpoint is still reachable and that authentication continues to function correctly after the migration.

    The primary risks are related to customizations that depend on features deprecated or removed in SPSE, such as SharePoint 2010 workflows, InfoPath Forms Services (after July 2026), Basic Authentication, or the Claims to Windows Token Service (C2WTS). Any custom code relying on these technologies should be reviewed and refactored if necessary.

    In my opinion, as a best practice, you should first perform the upgrade in a non‑production SPSE environment, redeploy all custom solutions, reconfigure app trusts, and thoroughly validate all business scenarios (PWA operations, add‑in functionality, and Remote Event Receivers) before proceeding with the production migration.

    You can read here for more information:

    Upgrade to SharePoint Server Subscription Edition

    What's deprecated or removed from SharePoint Server Subscription Edition

    Plan for app authentication in SharePoint Server

    Create high-trust SharePoint Add-ins

    Upgrading to Project Server Subscription Edition

    However, with this concern, I recommended to raise an official support ticket with Microsoft Support. Migration scenarios involving Project Server, app authentication, and farm‑specific configuration often require internal diagnostic tools and permissions that are not available through community forums.

    Hope my answer will help you.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.  

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-03-25T11:47:27.21+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    SharePoint Server Subscription Edition (SPSE) is designed to be very close to SharePoint Server 2019 in terms of server‑side features and SharePoint Framework (SPFx) support, so most 2019 customizations that are supported and not deprecated generally continue to work, but there are important points to plan and validate.

    Key platform alignment

    • SPSE has the same SPFx dependencies and requirements as SharePoint Server 2019.
    • Both support SPFx client‑side web parts and extensions, with SharePoint Server 2019/SPSE tied to SPFx v1.4.1 and the legacy gulp‑based toolchain.

    This means:

    • Any existing SPFx solutions that target SPFx v1.4.1 and work on SharePoint 2019 should be able to run on SPSE, assuming the same server‑side dependencies are met.

    Implications for components mentioned

    1. Provider‑hosted add‑in (PHA) with high‑trust
    • High‑trust PHAs are not covered explicitly in the provided material, but SPSE is positioned as a continuation of 2019 with the same app infrastructure requirements.
    • For any add‑in–based solution, ensure on SPSE:
      • App Management Service and dependent service applications are configured.
      • An App Catalog is created and configured.
    • These are required for deploying SPFx solutions and other app model packages.
    1. WSP solutions
    • The context does not explicitly describe WSP behavior in SPSE, but SPSE is an evolution of 2019, not a fundamentally new codebase.
    • Farm solutions that are supported and working on 2019 are expected to be validated on SPSE in a test environment; any deprecated APIs or unsupported features would need remediation.
    1. Remote Event Receivers (RERs)
    • RERs are not explicitly discussed in the context, but they are part of the SharePoint add‑in model that coexists with SPFx.
    • As with PHAs, ensure the app infrastructure (App Management Service, App Catalog) is correctly configured on SPSE.
    1. SPFx web parts and extensions
    • SPSE and SharePoint 2019 share the same SPFx baseline:
      • SPFx v1.4.1 is the supported version for client‑side web parts and extensions.
    • When targeting SPSE:
      • Use the SPFx v1.4.1 toolchain.
      • Follow the 2019/SPSE‑specific guidance for the gulp‑based environment.

    Planning and risk considerations

    1. Version alignment and toolchain
    • Confirm all SPFx solutions are built with SPFx v1.4.1.
    • If any solution was created with a later SPFx version for SharePoint Online, it will not be supported on SPSE and must be re‑scaffolded/ported to v1.4.1.
    1. App infrastructure on SPSE
    • Before migrating solutions, verify on SPSE:
      • App Management Service and related service applications are configured.
      • App Catalog site exists and is configured.
    • These are prerequisites for deploying SPFx packages and add‑ins.
    1. Solution inventory and compatibility check
    • For each solution (PHA, WSP, SPFx package, RER):
      • Identify the SPFx version used (where applicable) by checking:
        • .yo-rc.json
        • package.json
        • npm-shrinkwrap.json (if present)
        • node_modules/@microsoft/sp-webpart-base/package.json (version attribute)
      • Confirm it targets SPFx v1.4.1 for anything that must run on SPSE.
    1. Migration and testing strategy
    • Stand up a SPSE test farm and:
      • Configure app services and App Catalog.
      • Deploy WSPs, PHAs, RERs, and SPFx packages.
      • Validate key business scenarios: PWA integrations, resource and project operations, and any custom pages.
    • Pay particular attention to:
      • Any customizations that rely on deprecated APIs.
      • Any assumptions about URL structure, authentication, or claims that might differ between environments.
    1. Customization risk
    • Customization is required if:
      • Any SPFx solution uses a version newer than 1.4.1.
      • Any farm solution or add‑in uses APIs or features that are deprecated or removed in SPSE.
    • For SPFx, follow the SPFx 1.4.1 guidance and legacy gulp‑based toolchain instructions when rebuilding or adjusting solutions.

    Summary

    • SPSE and SharePoint 2019 share the same SPFx baseline (v1.4.1) and app infrastructure requirements, so supported SPFx solutions and app‑model components that work on 2019 are generally expected to work on SPSE once the same services (App Management, App Catalog) are configured.
    • The main risks are:
      • Solutions built for newer SPFx versions (must be ported to 1.4.1).
      • Any WSP/add‑in code using deprecated or unsupported APIs.
    • A structured test migration to a SPSE pilot farm, with full validation of PHA, WSPs, RERs, and SPFx components, is essential before production cutover.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.