Plenty of important business data lives in Excel files on SharePoint. Teams like it that way: everyone knows Excel, and SharePoint handles sharing and versions. The trouble starts when that data is needed somewhere else, such as a database, an ERP or a Power BI report. Then someone ends up exporting and importing it by hand.
For one client we built a small Windows service to close that gap. Every five minutes it checks a SharePoint library for updated workbooks, reads the rows and updates their SQL Server database. People keep working in Excel, and the database is never more than a few minutes behind.
The version that worked, but shouldn't stay
The first version used SharePoint's older client API and signed in with a stored username and password. It worked for years, and that is exactly the risk. Nobody looks at a sync that works, so nobody notices that:
- A real account's password is stored with the code, and anyone who can read the code can use it
- Changing that password means finding every place it is stored
- There is no handling for SharePoint throttling, so a busy afternoon can make the sync fail quietly
- Microsoft has been retiring older SharePoint authentication methods, so integrations built on them will eventually stop working
Moving to Microsoft Graph
We moved the service to Microsoft Graph, Microsoft's current API for Microsoft 365 data, using an app registration and OAuth instead of a stored password. The main changes:
- No password in the code. The service gets a short-lived access token from Microsoft Entra ID using its own app identity. The secret lives in protected configuration, and it can be moved to Azure Key Vault or replaced with a managed identity.
- Access limited to what it needs. The app gets permission to read files, not a person's full account.
- Throttling handled properly. When SharePoint answers with 429 "too many requests," the service waits the time SharePoint asks for in the Retry-After header and tries again, instead of failing.
- Clear errors. A 401 means get a new token, and a 403 means a permission is missing. Each one is logged with a message that tells a person what to fix.
Just as important is what we didn't change. The Excel parsing, the database updates and what the business sees all stayed exactly the same. Upgrading how an integration connects doesn't have to mean rewriting what it does.
Should you worry about your own syncs?
If you have a script, service or scheduled task that connects to SharePoint or Microsoft 365 and was written more than a few years ago, check three things. Does it use a real person's password? Does it use an older SharePoint API? Does anyone get told when it fails? If the answer to any of those is yes, it deserves a look before it breaks.
Excel on SharePoint can be a perfectly good data source. It just needs a reliable, secure path into the rest of your systems. That is what data centralization means for most of our clients. Start with a free assessment and we'll review the integrations you already have.