SharePoint, SPFx, and Power Platform Modernization for a Federal OIG in M365 GCC

The situation

The agency was running its day-to-day collaboration and internal operations on an aging SharePoint 2013 environment. Layered on top were years of accreted customizations: bespoke web parts wrapping front-end JavaScript libraries, plus inline JavaScript embedded in script editor web parts on individual pages. None of it was governed, and the underlying patterns were ones Microsoft had been steadily retiring from its modern stack.

The customizations still worked. They were also a liability.

Every change carried risk to ongoing audit and investigative workstreams, the talent pool for those technologies was shrinking, and the underlying farms were drifting further from the supported Microsoft 365 trajectory. Standing still was getting more expensive than moving.

The mandate was clear: get to a modern, governed M365 GCC posture, retire the legacy customizations, and leave behind something a small in-house team could maintain without specialist help.

The challenge

The work broke into five parallel problems:

1. Migrate active SharePoint workloads from on-prem SharePoint 2013 into M365 GCC without interrupting oversight operations.
2. Retire legacy SharePoint customizations and replace them with modern, supported equivalents in SPFx and Power Platform.
3. Decide, case by case, where the boundary between SPFx (pro-code) and Power Platform (low-code) should sit, and apply that line consistently across the estate.
4. Stand up new operational dashboards and integrated workflows that the legacy environment had never supported well, including Microsoft Graph reads across the M365 tenant.
5. Establish governance, security, and release practices the agency could sustain inside GCC compliance constraints, with a small operational footprint after handover.

The approach

The operating model

The engagement ran with a small specialist team (under five) working close to the agency's IT function. We kept governance light and decisions close to the engineers actually shipping the work.

That shape was deliberate. In a tenant carrying federal compliance obligations, a smaller team produces a cleaner audit trail and a smaller blast radius per change. It also forces architectural discipline: there is no headcount to absorb sprawl.

Rebuilding the intranet around the agency's structure

The migration was less about moving SharePoint and more about rebuilding the intranet around the structure of the agency. Rather than replicate the legacy site layout in a new tenant, the new intranet mirrored the agency itself: each office had a paired pattern of two SharePoint sites. A Team Site served the office's internal work and collaboration. A Communication Site gave the rest of the agency a single, predictable doorway to learn about that office and initiate requests into it. The split made the intranet legible in a way the legacy environment had not been: internal workspaces stayed private to the office, and outward-facing engagement had a consistent, navigable shape across the agency.

ShareGate handled the content move from on-prem SharePoint 2013 into modern SharePoint Online sites in M365 GCC. Customizations did not migrate; they were rebuilt or replaced. Legacy form and workflow logic was re-expressed in Power Apps and Power Automate, with the underlying business processes preserved and the legacy artifacts retired.

The cutover ran office by office rather than as a single switch. Navigation on both the legacy intranet and the new tenant was kept current as each office moved, so users always had a working path to the content they needed, and redirects on the legacy site forwarded straggler traffic to its new location.

Modern UI and UX patterns replaced classic team-site layouts, and the operational simplification target was kept honest: every portal that came across had to be one the agency still actively used.

Modernization at this scale is mostly the work of retiring what you do not bring. The platform move is the easy half.

Architecture: Power Platform first, SPFx where required

The clearest design decision was not what to build. It was where to draw the line between code and low-code, and then to hold that line across every workstream.

The legacy environment was an existence proof of what happens without that line. The accreted custom JavaScript and script editor web parts had not been written badly; they had been written without governance, without a release process, and without anyone deciding which work belonged in which surface. The maintenance liability that resulted was much of why modernization was needed in the first place.

The new rule was simple. Power Platform was the default. SPFx (SharePoint Framework) was used only where Power Platform could not meet the requirement.

Power Platform carried most of the work: smaller forms and workflows, plus a layer of operational reporting on top. Power Apps replaced the form-driven scenarios, Power Automate replaced the workflow logic, and Power BI replaced the ad hoc reporting that tends to grow up around aging portals.

SPFx was reserved for cases where it was the only viable tool. Those cases came in a few shapes: modern web parts that needed coded interactivity beyond what a low-code surface offers, application customizers and command sets where navigation, branding, or list behavior had to be tenant-consistent, field customizers for in-list rendering, and full SPFx single-page applications where an operational dashboard demanded richer interaction than a stack of web parts could provide. Several SPFx components called Microsoft Graph or external APIs to assemble cross-system views the legacy environment was not architected to support.

The discipline made every future change cheaper. SPFx work flowed through a developer release process. Power Platform work flowed through citizen-developer-friendly governance. Mixing those models, or letting unbounded custom JavaScript sneak back in, is where Microsoft 365 estates typically lose governance discipline.

Governance, security, and the GCC posture

GCC imposed its own constraints, and we treated those constraints as design inputs rather than as paperwork. Tenant configuration, identity and permission scopes for Graph and external integrations, Power Platform environment strategy, and release controls were defined together with agency stakeholders rather than retrofitted. The intent was an estate that fit inside agency policy on go-live, not one that needed a remediation pass after.

Deployment and release

SPFx components shipped through a release process aligned with the agency's existing change-management practices. Power Platform solutions moved through a managed environment progression so that low-code work was governed with the same rigor as code. Release cadence stayed predictable across workstreams.

In a federally compliant tenant, the smaller the team, the cleaner the audit trail. Discipline scales better than headcount.

The outcome

By close-out, the agency was running collaboration, internal portals, smaller forms, and operational reporting on a modern M365 GCC estate. Legacy SharePoint customizations were retired rather than carried forward. The SPFx and Power Platform footprints were both governed under sustainable release practices. Microsoft Graph integrations brought cross-tenant reads into the portal experience, a class of work the legacy environment was not architected to support.

Roughly a thousand users across audit and investigative functions moved onto the new estate. The under-five delivery team handed over a smaller, more maintainable surface area than the one they inherited, which was the actual point.

The engagement was completed and closed out.

What we took from it

A few lessons that travel beyond this engagement and that a federal program manager will recognize:

• Default to low-code. Reserve pro-code for the cases that actually require it. Most M365 modernization programs drift because they treat SPFx and Power Platform as parallel lanes of equal weight. They are not. Power Platform first, SPFx where required, and the rule written down somewhere a steering committee can refer to.
• Migration value lives in what you retire and in what you redesign, not in what you move. Decommission customizations that still technically function, and treat cutover as the moment to redesign information architecture rather than carrying the old structure forward. Budget for both explicitly.
• Phase the cutover. Keep navigation honest while you do. An office-by-office migration with redirects in place is far less disruptive than a single switch, but only if the navigation on both the old and the new tenant stays current as each phase lands. The migration story users actually experience is the navigation story.
• Governance is a deliverable, not a phase. GCC posture, identity scopes, environment strategy, and release controls should be designed into the first sprint, not bolted on before go-live. Retrofitting governance is the most expensive way to acquire it.
• Microsoft Graph repays its integration cost. Reaching across the tenant for cross-system reads turns a portal program into an operational platform. Designing for it from the start is far cheaper than adding it later.