All case studies
Case Study

Modernizing an Enterprise SharePoint & Power Platform Ecosystem

Consolidating fragmented collaboration, identity and automation into one governed Microsoft 365 platform

Enterprise TechnologyAnonymized20 min readPublished 20 Aug 2026Updated 21 Aug 2026

Anonymized. Real work with client, product and identifying details removed.

AzureMicrosoft 365SharePointPower AutomatePower AppsMicrosoft Entra IDMicrosoft GraphPower Platform

Executive Summary

The case. A large organization running Microsoft 365 has accumulated roughly a decade of SharePoint sites, InfoPath-era forms, hand-built workflows and departmental Power Platform apps. Nothing is broken enough to force a rewrite, and everything is tangled enough to make change expensive.

The problem being investigated. Not "how do we upgrade SharePoint" — the tenant is already on SharePoint Online. The real question is whether a platform that grew by accretion can be brought under a coherent information architecture, identity model and automation governance regime without a migration programme that stops the business for a year.

Why it matters. The cost of this kind of estate is rarely a licence line. It is the slow tax: every new request needs an archaeologist, every permission question needs a human, and every automation is a person rather than a process.

The decision involved. Whether to rebuild on a modern hub-and-spoke information architecture, to lift-and-shift and defer the problem, or to govern in place. This study argues for a phased consolidation with a governed landing zone, and is explicit about what that trades away.

Disclosure. This is an anonymized study. The scenario is assembled from patterns common to large Microsoft 365 estates; no client, tenant, system or dataset is identified, and every figure in Business Impact is labelled Illustrative, Estimated or Projected. Nothing here is a measured result.

01

Context

The organization is a multi-region enterprise of roughly 8,000 knowledge workers (assumption, used to size the architecture). It has been on Microsoft 365 for around eight years, having migrated from SharePoint Server. The tenant is healthy: licensing is current, identity is in Microsoft Entra ID, and the platform is not the constraint.

Business context

Collaboration is decentralized by design. Individual departments were given latitude to create sites and, later, Power Platform apps, because central IT could not service demand fast enough. That decision was correct at the time and is the direct cause of the present state — a useful thing to say plainly, because "who allowed this" is the least productive question available.

Technology context

The estate spans classic and modern SharePoint sites, a mix of flat and nested site collections, legacy workflow engines, and several hundred Power Platform objects distributed across a small number of environments. Microsoft Graph is used in places, mostly by point integrations written by different teams to solve the same problem.

Industry context

This shape is unremarkable. Most long-lived Microsoft 365 estates converge on it, because the platform makes creation cheap and consolidation expensive. The interesting question is not how it happened but what a realistic exit looks like.

02

Problem Statement

The estate has no navigable structure, no reliable permission model, and no boundary between "an app someone built" and "a system the business depends on".

Who is affected

  • Knowledge workers cannot find documents and default to asking a colleague — search returns results, but the results are not trusted because duplicates are everywhere.
  • Site owners inherited sites they did not create and cannot explain the permissions on.
  • Central IT is asked to support automations it did not build, cannot see, and has no runbook for.
  • Risk and compliance cannot answer "where does this category of data live" with evidence.

Current limitations

  • Permissions are granted directly to individuals in many places rather than through groups, so access review is manual and access removal is unreliable.
  • Business-critical automations run under the personal account of whoever built them.
  • There is no environment strategy: development, test and production coexist in the same Power Platform environment.
  • Retention and DLP were applied to the tenant, not to an information architecture, so they are simultaneously too broad and full of gaps.

Technical consequences

Change is expensive because impact cannot be assessed. Nobody can say with confidence which flows read a given list, so every schema change is a small crisis.

Business consequences

Two costs dominate: the time knowledge workers lose to retrieval, and the operational risk carried by automations with a single human point of failure. Both are real; neither has been measured here, and this study does not pretend otherwise.

03

Objectives

Success criteria, framed so each one could later be argued as met or not met.

  • Establish a navigable information architecture that a new joiner can traverse without tribal knowledge
  • Move permission assignment from individuals to Entra ID groups with a defined ownership and review cycle
  • Separate development, test and production for Power Platform so a change can be tested before it reaches the business
  • Bring business-critical automations off personal accounts and onto service identities with documented ownership
  • Reduce time-to-find for common document classes, measured against a baseline captured before any change
  • Make the estate assessable: a named owner and a data classification for every site
  • Modernize without a freeze — the business must keep shipping while consolidation runs
04

Current State

The estate was assessed by inventory rather than by interview, because owners consistently under-report what they have built.

DimensionObserved patternConsequence
Site topologyMixed flat and nested; several deep hierarchies inherited from SharePoint ServerNavigation depends on links people have bookmarked
PermissionsDirect user grants and broken inheritance in a significant minority of sitesAccess review is manual; leavers are missed
AutomationLegacy workflows alongside modern flows; ownership concentrated in individualsSingle points of failure with no runbook
EnvironmentsDev, test and production share one Power Platform environmentNo safe place to test a change
IntegrationMultiple bespoke Graph integrations solving overlapping problemsDuplicated effort; inconsistent throttling behaviour
Data lifecycleTenant-wide retention with no per-workspace classificationSimultaneously over-retaining and under-protecting

Note on method. The figures behind this table would come from tenant inventory tooling and Power Platform admin analytics. They are not reproduced here because they would be tenant-identifying, and inventing plausible ones would be worse than omitting them.

05

AI Opportunity

AI is genuinely useful here, but not for the part of the problem that actually hurts. Retrieval quality is a symptom; the cause is structure, ownership and permissions. Applying AI to an ungoverned estate produces a faster route to the wrong document, and inherits every permission defect underneath it.

The honest sequencing is: fix identity and information architecture first, then let AI operate on a corpus whose boundaries are known. That is why the verdict below is partial rather than positive.

AI is partially appropriate

Where AI creates value

  • Assisted metadata suggestion during migration, with a human approving the classification rather than accepting it silently
  • Duplicate and near-duplicate detection across sites, as a shortlist for owners to confirm
  • Drafting site descriptions and ownership summaries from existing content to seed the catalogue
  • Summarizing long-running approval threads for auditors, with the source thread always one click away

What should not be automated

  • Automated permission remediation — an incorrect revocation is an outage and an incorrect grant is a breach
  • Automated deletion or retention decisions on unclassified content
  • Answering "who should have access to this" without a human owner in the loop
  • Any assistant over the corpus before permissions are trustworthy — it would confidently surface what it should not
06

Alternatives

Three approaches were compared. The third is the recommendation, but the first is not a straw man — it is the correct answer for a smaller estate.

Option A

Govern in place

Leave the topology as it is. Apply policy, DLP and access reviews to what exists, and improve search through metadata and promoted results.

Advantages

  • Lowest disruption
  • No migration risk
  • Fastest to start
  • Preserves every existing link and bookmark

Disadvantages

  • Does not fix navigation
  • Permission debt remains
  • Governance sits on top of a structure that fights it
  • Cost recurs every year
Cost: LowRisk: LowScalability: PoorComplexity: Low

Option B

Big-bang rebuild and migrate

Design a target information architecture, build it, and migrate the estate to it in a single coordinated programme.

Advantages

  • Clean end state
  • One disruption rather than many
  • Forces classification decisions to be made

Disadvantages

  • High delivery risk
  • Long freeze on change
  • Business disruption concentrated
  • Requires accurate up-front inventory the organization does not have
  • Failure mode is a half-migrated estate
Cost: HighRisk: HighScalability: GoodComplexity: High

Option C

Phased consolidation onto a governed landing zone

Recommended

Stand up a governed target — hub-and-spoke IA, environment strategy, group-based access — then move workloads into it in waves, oldest and least-coupled first. The legacy estate is frozen for new creation but keeps working.

Advantages

  • Risk is bounded per wave
  • Business keeps shipping
  • Governance applies from day one to anything new
  • Each wave produces learning the next one uses
  • Can be paused without leaving a broken estate

Disadvantages

  • Two worlds coexist for a period
  • Requires sustained ownership over quarters not weeks
  • Slower to a clean end state
  • Needs discipline to prevent the legacy estate growing
Cost: MediumRisk: MediumScalability: GoodComplexity: Medium
07

Proposed Solution

A governed landing zone that new and migrated work moves into, with the legacy estate frozen for creation and retired wave by wave.

Components and responsibilities

  • Hub-and-spoke information architecture. A small number of hubs aligned to business domains, with flat site collections beneath them. Navigation and search scope come from hub association rather than folder depth.
  • Group-based access. Every site's permissions resolve to Entra ID groups. Direct user grants are treated as a defect, not a style choice.
  • Power Platform environment strategy. Separate development, test and production environments with DLP policies per environment, and a managed path to promote a solution between them.
  • Service identity for automation. Business-critical flows run under service principals with documented owners, not under the account of whoever built them.
  • A shared integration layer. One governed pattern for Microsoft Graph access, replacing the bespoke integrations that each re-solved throttling and consent.

Where a human stays in the loop

Classification, permission changes and retention decisions require a named owner to approve. This is not ceremony — these are the three operations where an automated mistake is expensive and hard to reverse.

08

Solution Architecture

The architecture is deliberately conventional. Novelty in a consolidation programme is a cost, not a feature.

Domain hubs (SharePoint Online)

Provide navigation, branding and search scope for a business domain. Hub association is the structural relationship; folder depth is not.

Workspace sites

Flat site collections associated to exactly one hub, each with a named owner and a data classification recorded at creation.

Provisioning service

The only supported route to a new site. Captures owner, classification and retention at creation time, so the catalogue is correct by construction rather than by later audit.

Microsoft Entra ID groups

The unit of access. Membership is reviewed on a defined cycle; site permissions reference groups only.

Power Platform environments (dev / test / prod)

Isolate change. Each carries its own DLP policy; solutions are promoted rather than rebuilt.

Graph integration layer

One governed pattern for Microsoft Graph access — consent, throttling and retry handled once instead of in every integration.

Estate catalogue

The system of record for owner, classification and lifecycle state per workspace. Feeds access review and retention.

Data flow

A request for a workspace enters the provisioning service, which captures owner and classification, creates the site, associates it to a hub, and registers it in the catalogue. Access is granted by adding the requester to an Entra ID group, never by a direct site permission. Automations built in the development environment are promoted to test and then production as a solution; in production they bind to a service identity rather than a person. Integrations that need tenant data call the Graph layer, which holds consent and applies throttling and retry centrally. The catalogue drives periodic access review, and retention policy is applied per classification rather than tenant-wide.

Integrations

  • Microsoft Graph for directory, site and file operations, through one governed layer
  • Power Automate to Dataverse and SharePoint Online via managed connectors constrained by per-environment DLP
  • Identity governance and access review over the same Entra ID groups that carry site permissions
  • Existing line-of-business systems reached through the integration layer rather than per-app connections

Security boundaries

  • Entra ID group membership is the access boundary; direct user grants are a defect to be remediated
  • Per-environment DLP separates connectors available in development from those available in production
  • Service identities carry least privilege scoped to the workload, not tenant-wide application permissions
  • Conditional Access governs the conditions of sign-in; the site permission model governs what is then reachable
  • Classification recorded at provisioning drives retention and protection, so policy follows the data

Human in the loop

  • Site classification is proposed at provisioning and confirmed by the owner
  • Permission changes to sites holding regulated content require owner approval
  • Retention and deletion decisions on unclassified content are never automatic
  • Migration wave sign-off is an explicit business decision, not a scheduler
09

Technology Stack

Existing platform capability throughout. The value here is in how the pieces are arranged and governed, not in adding new ones.

Collaboration

SharePoint OnlineMicrosoft 365Hub sitesManaged metadata

Application

Power AppsPower AutomatePower Platform solutions

Identity

Microsoft Entra IDEntra ID groupsConditional AccessAccess reviews

Integration

Microsoft GraphManaged connectorsService principals

Data

DataverseSharePoint listsManaged metadata service

Governance

Power Platform DLP policiesRetention labelsCentre of Excellence toolkit
10

Architecture Decisions

The three decisions that shaped everything else. Each is recorded with what it costs, because a decision without a stated trade-off is advocacy.

Decision 01

Adopt hub-and-spoke with flat site collections rather than nested hierarchies

The inherited estate contains deep hierarchies from SharePoint Server, where nesting was the primary structural tool. In SharePoint Online, hub association provides navigation and search scope without coupling permissions to depth.

Alternatives considered

  • Preserve existing nesting
  • Deep hub nesting
  • Flat sites with hub association

Reason

Flat sites keep the permission boundary and the navigation boundary independent. Depth couples them, which is precisely how the current estate acquired broken inheritance.

Benefits

  • Permissions stay comprehensible
  • Sites can be re-associated without moving content
  • Search scoping follows business domains
  • Lifecycle can be managed per site

Trade-offs

  • More site collections to administer
  • Navigation depends on hub configuration being maintained
  • Familiar folder mental model is lost for some users

Risks

  • Hub sprawl if hub creation is not itself governed
  • Users bookmark sites directly and bypass navigation

Decision 02

Grant access exclusively through Entra ID groups, never directly to users

A significant minority of sites grant permissions to individuals. Access review is therefore manual and leaver removal is unreliable.

Alternatives considered

  • Direct user grants
  • SharePoint groups only
  • Entra ID groups as the single unit of access

Reason

Only a directory group can be reviewed, attested and automatically emptied when someone leaves. A SharePoint group is invisible to identity governance.

Benefits

  • Access reviews become possible
  • Leaver process becomes reliable
  • Membership has one place to look
  • Supports attestation evidence

Trade-offs

  • Slower to grant one-off access
  • More groups to name and own
  • Requires a naming convention that survives reorganisation

Risks

  • Group sprawl without lifecycle rules
  • Owners approving reviews without reading them

Decision 03

Separate Power Platform environments and defer a full Dataverse migration

Development, test and production currently share one environment. A separate question — whether departmental apps should move from SharePoint lists to Dataverse — was deliberately not bundled into this decision.

Alternatives considered

  • Single environment with naming conventions
  • Separate environments only
  • Separate environments plus immediate Dataverse migration

Reason

Environment separation removes the largest operational risk and can be done without touching app data. Bundling a storage migration would make an achievable change into a programme, and the two are not causally linked.

Benefits

  • Changes can be tested before reaching the business
  • DLP can differ per environment
  • Solution promotion becomes a repeatable path
  • Blast radius of a bad change is bounded

Trade-offs

  • Apps must be repackaged as solutions
  • More environments to license and administer
  • Some connection references need rework

Risks

  • Teams continuing to build directly in production
  • Environment sprawl if creation is not governed
  • Deferred Dataverse decision being read as never
11

Implementation Approach

Phased so that each wave produces evidence the next one uses. No phase requires a change freeze.

  1. 01Discovery and inventory

    Weeks 1–6

    Build the estate inventory from tooling rather than interviews: sites, permission anomalies, flow ownership, connector usage. Capture a retrieval-time baseline before any change, so later claims can be tested.

    Milestones

    • Estate inventory complete
    • Permission anomaly list produced
    • Automation ownership mapped
    • Baseline measurement captured

    Success measures

    • Percentage of estate inventoried
    • Count of sites with no identifiable owner

  2. 02Landing zone

    Weeks 6–14

    Stand up the target: hub structure, provisioning service, group model, environment strategy and DLP. Nothing migrates yet. Freeze creation in the legacy estate so the problem stops growing.

    Milestones

    • Hubs established
    • Provisioning service live
    • Dev/test/prod environments with DLP
    • Legacy creation frozen

    Success measures

    • Time to provision a governed workspace
    • Percentage of new workspaces created through the service

  3. 03Pilot wave

    Weeks 14–22

    Migrate two or three low-coupling domains. The purpose is to find what the inventory missed — it always misses something — and to produce a runbook that later waves follow.

    Milestones

    • Pilot domains migrated
    • Runbook published
    • Rollback exercised at least once

    Success measures

    • Defects found per migrated site
    • Rollback time observed in exercise

  4. 04Governed automation

    Weeks 18–30, overlapping

    Move business-critical flows onto service identities with named owners. Publish a supported pattern for Graph access and retire the bespoke integrations that duplicate it.

    Milestones

    • Critical flows on service identities
    • Graph integration pattern published
    • Duplicate integrations retired

    Success measures

    • Count of critical automations still bound to a personal account

  5. 05Waves at scale

    Quarters 2–4

    Run the remaining domains through the runbook, oldest and least-coupled first. Report per wave rather than per programme, so a pause is a decision rather than a failure.

    Milestones

    • Domains migrated by wave
    • Legacy estate reduced per quarter

    Success measures

    • Sites remaining in the legacy estate
    • Access review completion rate

  6. 06Steady state

    Quarter 4 onward

    Consolidation becomes operations: access reviews on cycle, catalogue maintained at provisioning, environment strategy enforced by policy rather than by memory.

    Milestones

    • Access review cycle running
    • Catalogue coverage sustained
    • Legacy estate retired or formally accepted

    Success measures

    • Access review completion rate
    • Percentage of estate with owner and classification
12

Business Impact

None of these are measured results. They are the quantities this architecture is designed to move, with the basis of each estimate stated so a reader can disagree with the arithmetic.

Read the labels. Illustrative means the figure demonstrates the shape of an argument. Estimated means derived from stated assumptions. Projected means a modelled forward view. None of them is Measured, and none describes delivered client work.

Document retrieval time

-30%

Projected

Modelled from the reduction in duplicate results once consolidation removes redundant copies, against a baseline captured in Discovery. Depends entirely on that baseline existing — without it the claim is untestable.

Sites with a named owner and classification

95%

Estimated

Estimated on the assumption that provisioning becomes the only supported creation route and legacy creation is frozen. The residual is orphaned sites requiring a business decision to adopt or retire.

Critical automations on service identities

100%

Projected

A target rather than a forecast. The count is knowable from inventory; reaching it is a scheduling question, not a technical one.

Manual effort in quarterly access review

-50%

Illustrative

Illustrative only. Group-based access makes review tractable rather than manual, but the size of the saving depends on the current review process, which was not measured.

13

Risks & Constraints

Including the risks that argue against the recommendation.

RiskCategoryImpactProbabilityMitigation
Migration breaks links, bookmarks and embedded references that nobody inventoriedOperationalHighHighRedirects for moved content, a pilot wave whose explicit purpose is to find what the inventory missed, and per-wave rollback exercised at least once before scale.
Permission remediation removes access someone genuinely neededSecurityHighMediumRemediate in report-only mode first, require owner confirmation before revocation, and keep a fast, documented restore path. Never automate revocation.
Consolidation stalls midway, leaving two estates permanentlyOrganizationalHighMediumFreeze legacy creation at the landing-zone phase so the problem cannot grow, report per wave rather than per programme, and design each wave to leave a coherent state if the next never happens.
Environment separation is bypassed and teams keep building in productionOperationalMediumHighMake the governed path faster than the ungoverned one, restrict maker permissions in production, and monitor for objects created outside the promotion path.
Governance is applied to structure but never to Graph integrationsTechnicalMediumMediumPublish the supported integration pattern before the waves begin, and treat retirement of duplicate integrations as a tracked deliverable rather than a cleanup.
14

Security & Governance

Identity and access

Entra ID groups are the unit of access, which is what makes attestation possible at all. Conditional Access governs the conditions under which a session is established; the site permission model governs what that session can then reach. Conflating the two is a common and expensive mistake — Conditional Access is not a substitute for a permission model.

Data protection

Classification is captured at provisioning rather than inferred later. Retention and protection policies then follow classification, which is the difference between policy that fits the data and policy that was applied to a tenant and hoped for the best.

Automation governance

Per-environment DLP separates what a maker can connect to in development from what is permitted in production. Business-critical automations run under service identities with least privilege scoped to the workload — a tenant-wide application permission granted for convenience is the quiet failure mode here.

Auditability

The estate catalogue is the system of record for owner, classification and lifecycle state. Without it, access review degrades into asking people whether they still need something, which reliably produces "yes".

Human oversight

Classification, permission change and retention decisions require a named human owner. These are the operations where an automated error is expensive and slow to reverse, and they are deliberately excluded from any automation in this design.

15

Trade-offs

What this architecture gives up, stated plainly.

Governance vs Speed of self-service

Provisioning through a service is slower than clicking "create site". The mitigation is to make the governed path genuinely fast — if it is not, people route around it, and the estate regrows exactly as before.

Phased consolidation vs A clean end state

Two worlds coexist for several quarters. Accepted deliberately: the alternative is a freeze the business will not tolerate, and a half-finished big-bang is worse than a paused phase.

Flat site collections vs A familiar folder hierarchy

Some users lose the nesting mental model. Accepted because coupling permissions to depth is the specific defect being removed.

Group-based access vs Convenience of one-off grants

Granting an individual access takes longer. That friction is the control — a direct grant is invisible to review by construction.

Deferring Dataverse vs A single storage story

Departmental apps stay on SharePoint lists for now. Bundling that migration would convert an achievable change into a programme; the decision is deferred, not declined.

16

Strategic Recommendation

The recommendation, with the conditions it depends on.

Adopt Option C — phased consolidation onto a governed landing zone — and freeze creation in the legacy estate at the point the landing zone goes live.

Option A does not fix navigation or permission debt and re-incurs its cost every year. Option B concentrates risk in a programme whose success depends on an inventory the organization does not yet have, and whose failure mode is a permanently half-migrated estate. Option C bounds risk per wave, keeps the business shipping, and applies governance to everything new from day one. Its weakness — two worlds coexisting — is real but is a managed condition rather than an unbounded risk, provided legacy creation is frozen early. That freeze is the load-bearing part of the recommendation.

Conditions

  • Legacy creation is frozen when the landing zone goes live, or the estate grows faster than it consolidates
  • A retrieval baseline is captured in Discovery, or the retrieval claims can never be tested
  • Named owners exist per domain and are given time, not just accountability
  • The governed provisioning path is faster than the ungoverned one it replaces

Risks

  • Programme fatigue across multiple quarters
  • Ownership vacancies as people move roles mid-programme
  • Pressure to accelerate by skipping the pilot wave, which is where the unknown unknowns surface

Next steps

  • Run the inventory and capture the retrieval baseline before any structural change
  • Agree the hub taxonomy with business domain owners, not with IT alone
  • Stand up the landing zone and freeze legacy creation on the same day
  • Select pilot domains for low coupling rather than for enthusiasm
  • Publish the Graph integration pattern before the first wave, not after
18

References

Public vendor documentation. No proprietary or client material is cited.

  1. Information architecture in the modern SharePoint experience — Microsoft Learn · Documentation Source (opens in a new tab)

    Basis for the hub-and-spoke and flat site collection approach.

  2. Power Platform environments overview — Microsoft Learn · Documentation Source (opens in a new tab)

    Underpins the dev/test/prod environment strategy decision.

  3. Data loss prevention policies (Power Platform) — Microsoft Learn · Documentation Source (opens in a new tab)

    Per-environment connector governance.

  4. Power Platform Center of Excellence (CoE) toolkit — Microsoft Learn · Documentation Source (opens in a new tab)

    Inventory and adoption tooling referenced in Discovery.

  5. Microsoft Graph overview — Microsoft Learn · Documentation Source (opens in a new tab)

    The integration surface consolidated behind one governed pattern.

  6. What is Conditional Access? — Microsoft Learn · Documentation Source (opens in a new tab)

    Cited to distinguish sign-in conditions from the permission model.

  7. Introducing the SharePoint Migration Tool — Microsoft Learn · Documentation Source (opens in a new tab)

    Migration tooling considered for the wave approach.

17

Key Takeaways

01

The estate is not disordered because people were careless; it is disordered because creation was cheap and consolidation was not. Any plan that does not change that economics will be repeated.

02

Freezing creation in the legacy estate is the highest-leverage single action, and it costs nothing technically.

03

Coupling permissions to site depth is the specific defect. Flat sites with hub association decouple navigation from access.

04

A permission model that cannot be reviewed is not a permission model. Directory groups make attestation possible; SharePoint groups do not.

05

AI belongs after the information architecture, not instead of it — an assistant over an ungoverned corpus inherits every permission defect underneath it.

06

Environment separation delivers most of the operational safety and does not require a storage migration to do it.

07

Every claim in this study that could have been a number is labelled as an estimate, because the baseline that would make it a measurement has not been taken.

Working through a similar architecture or AI decision? I am happy to talk it through.

Get in touch