How SharePoint Records Management Cut Workflow Time by 65% for a 1500-Employee Retail Technology Company
A case study on modernizing SharePoint records management and document retention for a Finance department, including a full SharePoint 2010 migration and a Nintex to Power Automate migration for four business-critical workflows, without losing a single file.
Executive Summary
A national retail technology company running self-service kiosks across North America was operating its Finance department on an unsupported, on-premises SharePoint 2010 environment. Code Creators completed a full SharePoint 2010 migration for the client’s entire Finance site, 24.75 GB across 243,677 items, 159 subsites, and 2,991 lists, to SharePoint Online, modernizing SharePoint records management and document retention along the way, and rebuilt the four business-critical Nintex workflows still in active use through a Nintex to Power Automate migration. The migration preserved 100% of documents, metadata, and version history, cut workflow processing time by roughly 65%, and removed the security exposure of an unsupported platform. The project ran for 12 weeks and was followed by 30 days of post-migration support.
About the Client
The client is a national retail technology company that operates a large network of self-service kiosks across the United States and Canada, processing high volumes of financial transactions on behalf of retail partners. With roughly 1,500 employees and Finance operations split across multiple regional offices, the company’s document and workflow footprint had grown organically for more than a decade inside a single SharePoint 2010 hub site.
The Finance department sat at the center of that environment, relying on it for financial reporting, vendor documentation, audit trails, and internal approval routing. Because the company operates in a regulated, transaction-heavy segment of retail, the Finance site held compliance-sensitive records, audit logs, reconciliation reports, and vendor contracts, that could not tolerate data loss or an access-control gap during migration. The environment’s age and scale, and the fact that Finance leadership had limited visibility into which of its workflows were still active, made this a higher-complexity migration than a typical department-level move.
The Problem
By early 2025, the client’s SharePoint 2010 on-premises Finance site had become both an operational bottleneck and a compliance liability. The platform had exited mainstream Microsoft support years earlier, meaning the environment no longer received the security patches that a system holding financial records and compliance documentation needs. IT leadership flagged this as an unacceptable risk heading into the next audit cycle.
Operationally, the impact was just as real. The Finance site had accumulated 24.75 GB of content across 243,677 items, spread over 159 subsites and 2,991 lists, the kind of sprawl that happens when a hub site is never re-architected for a decade. Locating the correct version of a financial report or vendor document routinely took Finance staff far longer than it should have, and the site’s permission model had drifted so far from any documented structure that IT could no longer confidently say who had access to what.
Approval routing was handled through Nintex workflows built on the SharePoint 2010 workflow engine. Out of 540 workflows that existed somewhere in the broader environment, only 4 were still actively used by Finance, and those 4 governed real business processes, including document approvals and task routing that finance staff depended on weekly. If the platform failed before a migration was complete, those approval chains would stop functioning entirely, with no modern equivalent to fall back on. Left unresolved, the client faced a combination of security exposure, audit risk, and a growing productivity tax as staff time went into manual document archaeology that should have gone into financial reporting.
What We Discovered
Before touching a single file, Code Creators ran a full pre-migration assessment of the Finance site to understand exactly what needed to move, what could be retired, and where the real risk was hiding.
Content Inventory for the SharePoint 2010 Migration
We inventoried all files, lists, workflows, and metadata across the site, flagging critical business documents, financial reports, reconciliation records, and vendor files, for priority handling. This inventory is what surfaced the full scope: 243,677 items across 2,991 lists and 159 subsites, far larger than the client’s own estimate going into the engagement.
Permissions Audit
A permissions audit across all 159 subsites confirmed what IT suspected: years of ad hoc access grants had created significant permission sprawl, with inconsistent inheritance, orphaned groups, and department-level access that no longer matched the org chart. Every custom configuration and role-based policy was documented, giving the team a deliberate blueprint for rebuilding the structure in SharePoint Online.
Workflow Analysis for the Nintex to Power Automate Migration
Of the 540 workflows technically present in the broader SharePoint environment, our review confirmed only 4 had been used within the prior six months and were tied to real Finance processes, primarily document approval and task routing built on Nintex. Each was mapped step by step: triggers, approval logic, notifications, and the SharePoint 2010-specific connectors it depended on, several of which relied on SOAP-based endpoints with no direct equivalent in the cloud. That gap became the central design constraint for the rebuild, since a literal lift-and-shift of the workflow logic wasn’t possible. Each flow had to be reconstructed natively in Power Automate.
SharePoint Document Retention Review
Version history review also turned up gaps: several compliance-critical libraries weren’t consistently retaining prior versions, a finding that directly shaped the SharePoint document retention and DLP policies we configured later in the project.
The SharePoint Records Management Solution
Our objective was a SharePoint records management environment that gave the Finance site no data loss, functioning approval workflows, and a permissions model the client’s IT team could actually explain and maintain going forward.
We selected the SharePoint Migration Tool (SPMT) as the primary migration engine after confirming it could handle the client’s folder structures, metadata, and version history requirements without third-party licensing overhead; it was finalized only after validating file-size limits against the client’s largest financial report libraries. Because the client’s data lived in a single hub site, we preserved that same structure in SharePoint Online, keeping the navigation and mental model Finance staff already knew while cleaning up the permission sprawl underneath it.
The project ran in five phases:
- Pre-Migration Assessment,
- Phased Content Migration with Validation,
- Workflow Redevelopment in Power Automate,
- Security and Permissions Configuration
- End-user and Administrator Training with Post-Migration Support.
Content migration was staged by priority: document libraries and custom lists with compliance relevance moved first, with folder hierarchies and metadata preserved throughout, and large files handled individually to stay within SharePoint Online’s file-size limits. Each of the 4 Nintex workflows was rebuilt from its documented logic, since we had confirmed no direct one-to-one automated conversion path existed for the SOAP-dependent actions involved.
Challenges Overcome
The permissions sprawl uncovered during the audit turned out to be more extensive than the client’s own IT team expected, with several subsites carrying access grants that no longer traced back to an active employee or role. We addressed this by rebuilding role-based access control (RBAC) for the Finance department from the documented policy baseline, which added time to the security phase but eliminated the risk of carrying legacy access errors into the new environment.
The rebuilt RBAC model was reviewed and formally signed off by Finance leadership and IT security before a single permission was applied in production, giving the team a documented, approved baseline to build from during the migration.
The Nintex-to-Power-Automate conversion was the other significant hurdle. Because several workflow actions depended on SOAP-based, on-premises-only connectors, we couldn’t use an automated migration path for any of the 4 workflows. Each had to be reconstructed from its mapped logic and then run through end-to-end and user testing to confirm it matched the original approval behavior before go-live. That testing included replaying a sample of real historical approval requests through each rebuilt workflow and comparing the outcome against what the original SharePoint 2010 workflow had actually done, which is what gave Finance leadership confidence to sign off on cutover.
Coordinating validation windows across Finance and IT stakeholders, all of whom had day jobs beyond this project, also required a tighter-than-usual review cadence to keep the 12-week timeline on track. All 4 workflows went live in a single weekend cutover, so Finance staff arrived Monday morning to a fully working system with no approval backlog and no in-flight requests lost in the switch.
Results & Business Impact
The migration moved all 243,677 items, documents, custom lists, and metadata, into SharePoint Online with zero data loss and full version history intact for compliance-critical libraries. With the 4 rebuilt Power Automate workflows live, approval and task-routing processes that previously ran on an unsupported 2010 engine now run roughly 65% faster, largely because Power Automate’s cloud-native triggers eliminated the polling delays inherent to the old Nintex-on-2010 setup.
On the security side, the client’s Finance data is now protected by Data Loss Prevention (DLP) policies and SharePoint document retention rules configured through Microsoft Purview, alongside multi-factor authentication enforced at the identity level through Microsoft Entra ID, none of which the on-premises SharePoint 2010 environment could support. Rebuilt RBAC replaced the permission sprawl identified in the audit, giving IT a documented, defensible access model for the first time in a decade. Audit logging was configured specifically around sensitive document activity, closing the compliance gap that had been the original trigger for the project.
The day-to-day impact varied by role. Finance users now search and retrieve documents through a single, well-organized library, replacing what had been a decade of accumulated subsites with no consistent structure, and workflow approvals that used to require manually forwarding an email now arrive and clear through Power Automate the same day. IT administrators manage one documented permissions model with clear ownership for every access grant and a defined process for changing it going forward, closing out a decade of undocumented exceptions.
For audit and compliance work, retention and DLP policies now apply automatically based on document metadata, giving the compliance team a defensible, evidence-backed answer whenever an auditor asks how a specific record has been retained and protected, without a manual search through a shared drive to reconstruct the answer.
Lessons Learned
A few things from this project are worth carrying into any legacy SharePoint migration:
- Inventory before you estimate: The client’s own sense of scope, a single Finance site, a handful of workflows, undercounted the reality by a wide margin once we ran the actual content and workflow audit. Any migration timeline or cost estimate built before a full inventory is simply a guess.
- “Still exists” and “still active” are different questions: 540 workflows existed somewhere in the environment; only 4 had been touched in six months and mattered to the business. Treating all 540 as in-scope would have tripled the effort for no operational benefit. The six-month activity window we used is a simple, defensible way to separate real scope from historical clutter.
- Permission sprawl is a governance symptom: A decade of ad hoc access grants complicates far more than the migration itself. It’s usually a sign that access reviews haven’t happened on any cadence. We treated the permissions audit as an opportunity to hand the client a documented, defensible RBAC model built for how the organization actually works today.
- Don’t trust automated workflow conversion for on-prem-specific logic: Nintex workflows built on SOAP-based, on-premises-only connectors have no reliable one-click migration path to Power Automate. Budgeting time up front to manually map and rebuild each workflow avoided a false start partway through the project.
Client Testimonial
“We knew our SharePoint 2010 environment was a ticking clock, but we didn’t realize how much permission sprawl and workflow risk had built up underneath it until Code Creators laid it out for us. What mattered most was that they didn’t just lift and shift our problems into the cloud, they rebuilt our approval workflows and access controls properly. Our Finance team hasn’t lost a single document, and approvals that used to sit in a queue now move the same day.”
Director of Finance Operations – Retail Technology Company
Frequently Asked Questions
For a single hub site with a similar profile to this project, roughly 25 GB across 240,000+ items, a few thousand lists, and a handful of active workflows, expect around 10 to 14 weeks from pre-migration assessment through go-live and validation. Timelines extend significantly if content volume is much larger; workflows are more numerous, or stakeholder’s availability for validation is limited.
Workflows built on the SharePoint 2010 workflow engine, especially Nintex flows using SOAP-based or on-premises-only connectors, generally have no direct migration path to SharePoint Online. They need to be redeveloped natively in Power Automate based on the original workflow documented logic. That’s why workflow analysis should happen before migration begins.
A permissions audit should happen before migration starts. Legacy environments accumulate inconsistent inheritance and orphaned access grants over time, what’s often called permission sprawl. We recommend rebuilding role-based access control from a documented policy baseline, so the client ends up with an access model IT can maintain.
SharePoint document retention refers to the rules that determine how long content is kept and when it can be disposed of, often tied to compliance or legal requirements. During a SharePoint 2010 migration, retention settings and version history don’t always carry over automatically, so validating that document retention policies are correctly configured in the new environment should be treated as a required step in the migration plan.
Not when the migration is properly staged and validated. SPMT and comparable tools are built to preserve folder structures, metadata, and version history, but validation checks after migration are what actually confirm nothing was dropped, particularly for large files near SharePoint Online’s size limits. Post-migration validation and error resolution should be treated as a required phase.
SharePoint Online sits inside Microsoft 365 and Microsoft Entra ID, which brings capabilities an on-premises SharePoint 2010 environment has no path to: Data Loss Prevention (DLP) policies and retention policies managed through Microsoft Purview, multi-factor authentication (MFA) enforced through Microsoft Entra ID, and detailed audit logging for sensitive content. These protections live in the surrounding Microsoft 365 identity and compliance platform, and they only become available once content moves into the cloud. SharePoint 2010, particularly once out of mainstream support, also stops receiving the security patches that come with an actively maintained platform.
Often less than it appears. For instance, in this project, only 4 of 540 workflows present in the broader environment were still active and tied to real business processes; the rest were dormant and excluded from scope. A content and workflow inventory early in the assessment phase is what separates ‘what a business actually uses’ from ‘what has simply accumulated over time’.
Standard Copilot supports drafting, summarization, and meeting intelligence within apps like Word, Excel, Outlook, Teams, and SharePoint, the capabilities used throughout this engagement. Microsoft 365 Copilot agents go further, enabling automation of multi-step workflows such as report generation, approval routing, and task follow-ups, typically built using Copilot Studio. Once Copilot data governance and adoption are established, as they were here, organizations often explore Copilot agents as a separate, later-scoped phase once departments identify specific processes worth automating.
Facing a Similar Legacy SharePoint Challenge?
If your organization is running a Finance, HR, or operations team on an aging, unsupported SharePoint environment, the risk compounds every quarter you wait. Schedule a consultation with Code Creators to get a clear picture of what needs to move, what can be retired, and what a realistic migration timeline looks like for your environment.
