A provincial Crown corporation in the utilities sector was running SharePoint environments spanning multiple on-premises versions — 2010, 2013, 2016, and 2019 — alongside growing records and information management obligations. The environments needed daily monitoring, performance management, and troubleshooting, and the organization needed a SharePoint Subject Matter Expert providing technical guidance across the enterprise environment.
The strategic question was not whether to modernize, but how: migrate years of content, permissions, and records to Office 365 without disrupting a utility that cannot stop operating — and do it in a way that left the information architecture cleaner than it started.
Running SharePoint 2010, 2013, 2016, and 2019 side by side is not a technology choice. It is the accumulated result of years of deferred decisions: each version introduced for a reason, each one kept because something still depended on it, each one adding to the maintenance surface. The environments needed daily monitoring, performance management, and troubleshooting — work that consumed the team's time without moving the organization forward. Every version carried its own patching, its own quirks, its own content, and its own permissions model. The organization was paying to maintain four platforms to do the job of one.
The content told the same story. Years of sites, libraries, lists, and documents had accumulated across the environments — some current, some duplicated, some belonging to teams that no longer existed. Permissions had been layered over time: granted for a project, never revoked, nested through groups whose membership nobody could fully explain. The information architecture — taxonomies, site collections, policies — had grown organically, which meant it reflected the organization's history more than its current needs.
A utility cannot stop operating for a migration. Field work, customer service, regulatory reporting, and operational coordination depend on the systems that hold their content and records. Any migration approach that required a clean break — a weekend where everything moved at once, with the business waiting on the other side — was not a real option. The migration had to happen while the organization kept working, with each wave validated before the next one began.
The records and information management obligations added a second constraint. A Crown corporation does not just move content; it moves records with retention, disposition, and accountability requirements attached. A migration that lost track of what a document was, who owned it, or how long it had to be kept would not be a successful migration, no matter how cleanly the files moved. The information architecture had to be maintained and improved through the move — taxonomies, site collections, policies, procedures — not just carried across.
The organization needed a SharePoint Subject Matter Expert providing technical guidance across the enterprise environment: someone who could design the target architecture, run the migration, and keep the existing environments healthy through the transition. The strategic question was not whether to modernize, but how — and the answer had to leave the information architecture cleaner than it started.
The engagement combined SharePoint SME leadership with hands-on migration delivery. Solution architectures were designed for the SharePoint and M365 environment — including scalability, performance, security, maintainability, and integrations — and validated against the organization's objectives and records requirements.
Information architecture was analyzed and maintained: organization taxonomies, site collections, policies, procedures, and solutions. Document libraries, enterprise lists, and site collections were recreated with permissions verified. Sites were remediated post-migration in collaboration with Scrum Masters, business analysts, and business users.
Migration execution used ShareGate to move SharePoint sites to Office 365 Online, with backup and restore procedures for SQL content databases. Daily monitoring, analytics reporting, performance analysis, and troubleshooting kept the environment healthy through the transition. Testing strategies and plans validated deliverables against business requirements. SharePoint Online development best practices were recommended and adopted, and the organization gained a supportable, cloud-native SharePoint environment.
The sequencing was deliberate: architecture and information architecture first, migration second. Migrating content into a target that has not been designed is how organizations end up with the same problems on a new platform — the sprawl, the broken permissions, the unfindable content, all carried forward at migration cost. So the first work was designing solution architectures for the SharePoint and M365 environment, covering scalability, performance, security, maintainability, and integrations, and validating them against the organization's objectives and records requirements.
Information architecture received the same priority. Taxonomies, site collections, policies, procedures, and solutions were analyzed and maintained — not copied blindly from the old environments, but reviewed against how the organization worked now. Document libraries, enterprise lists, and site collections were recreated in the target with permissions verified, rather than migrated with their accumulated history intact. That recreation was a conscious trade-off: it cost more effort upfront than a straight copy, and it produced a cleaner, more governable estate on the other side.
Migration execution used ShareGate to move SharePoint sites to Office 365 Online, with backup and restore procedures for SQL content databases providing a safety net underneath every wave. The migration was sequenced, not big-bang: sites moved in planned waves, each one validated before the next began. That sequencing was the answer to the utility's central constraint — the business kept operating, because no wave was declared done until it was verified.
Daily monitoring, analytics reporting, performance analysis, and troubleshooting kept the environment healthy through the transition, across both the legacy environments still running and the new environment coming online. Testing strategies and plans validated deliverables against business requirements, so the migration was measured against what the business needed, not just against whether the files arrived.
Post-migration remediation was treated as part of the migration, not as cleanup afterward. Sites were remediated in collaboration with Scrum Masters, business analysts, and business users — the people who owned the content and knew whether it had landed correctly. SharePoint Online development best practices were recommended and adopted, so the new environment was built to a standard the internal team could maintain. The engagement combined SME leadership with hands-on delivery throughout, because a migration of this kind needs both: the architecture judgement to design the target, and the operational discipline to move the content without breaking the business.
A migration of this size succeeds or fails on communication as much as on tooling. Site owners knew what was moving, when it was moving, and who to contact if something looked wrong — before their wave began, not after. Each wave had validation behind it: content checked, permissions confirmed, owners verifying their own sites, issues triaged and resolved before the next wave started. Backup and restore procedures for the SQL content databases meant every wave had a way back, which is what allowed the team to move decisively instead of cautiously. The cutover discipline was the quiet part of the engagement: no single dramatic moment, just wave after wave landing cleanly because the preparation, the validation, and the communication were done properly every time.
The organization moved from fragmented on-premises SharePoint versions to a governed Office 365 environment — with information architecture maintained, permissions verified, sites remediated, and records obligations supported. The migration was delivered without disrupting utility operations, and the estate that resulted was supportable by the internal team going forward.
[Quantified migration and performance metrics to be confirmed by Harjot before publication.]
The most concrete change was consolidation: four on-premises SharePoint versions, each with its own maintenance burden, replaced by a single cloud-native Office 365 environment. The daily monitoring, performance management, and troubleshooting that had consumed the team's time across four platforms now focused on one. That consolidation is not just a simplification. It is the removal of the end-of-support exposure, the patching burden, and the performance drag that came with running aging versions side by side.
The information architecture changed too. Taxonomies, site collections, policies, and procedures were maintained and improved through the move, not just carried across. Document libraries, enterprise lists, and site collections were recreated with permissions verified — which meant the new environment started from a known-good state rather than inheriting a decade of layered access. Post-migration remediation, done in collaboration with Scrum Masters, business analysts, and business users, meant the content landed correctly and the people who owned it confirmed it.
The organization can now run its SharePoint environment as a single, governable platform. Content is findable in an architecture designed for how the organization works now. Permissions are verifiable, because they were rebuilt and verified rather than copied. Records obligations are supported by an architecture that was validated against them, not by an environment that predated them.
The internal team can now maintain and extend the environment under SharePoint Online development best practices, rather than keeping four legacy versions alive. New sites, libraries, and solutions arrive into a governed estate with standards to follow — which is the difference between an environment that stays clean and one that starts drifting the day the migration ends.
What carries forward is a supportable, cloud-native SharePoint environment and the practices that keep it that way: the solution architecture, the maintained information architecture, the verified permissions model, the development best practices, and the remediation discipline the team practiced through the migration. The organization did not just move platforms. It moved to a way of running SharePoint that does not require another migration to fix — an estate the internal team can support, extend, and govern going forward, and a utility that never had to stop operating to get there.
The longer-term value of the migration is what it unlocked beyond SharePoint itself. A single cloud-native environment integrates naturally with the rest of Microsoft 365 — Teams, OneDrive, and the Power Platform — so the organization's collaboration, records, and automation can build on one governed foundation instead of four aging ones. Records and information management teams work from an architecture that was designed with their obligations in mind, rather than fighting an environment that predated them. And the next modernization — whether that is Copilot readiness, Power Platform governance, or deeper automation — starts from a known-good estate instead of a fragmented one. Migrations are often judged on the day the last wave lands. This one will be judged on the years that follow, and the foundation it left behind is what makes those years easier.
[Additional quantified outcomes — sites and content migrated, versions decommissioned, performance measures — to be confirmed by Harjot before publication.]
This case study is based on Harjot Singh's key-personnel project work. It is marked DRAFT pending Harjot's verification of facts, metrics, and framing before any publication.