For the extractor, the realistic Microsoft/O365 options are:
|
Option |
What it is |
Good fit here? |
|---|---|---|
|
Microsoft Graph API |
Direct API access to SharePoint content |
Very strong |
|
SharePoint REST API |
SharePoint’s native REST endpoint |
Very strong |
|
Microsoft Graph PowerShell |
PowerShell wrapper around Graph |
Strong, especially for a demo |
|
Power Automate cloud flow |
Microsoft-managed workflow engine |
Possible, especially if already licensed |
|
Azure Logic Apps |
More enterprise/server-side workflow automation |
Possible, but heavier |
|
Azure Function / scheduled Python |
Hosted code that performs the extraction |
Strong eventual production option |
|
CLI for Microsoft 365 |
Command-line wrapper for M365 APIs |
Useful, but only if approved |
|
PnP PowerShell |
Excellent SharePoint automation toolkit |
Technically great, but community-supported |
Markdown in the middle, and only in the middle.
This does not make Markdown the final outage format. nginx serves plain static HTML.
But I am warming to this:
SharePoint / ASPX
↓
extract meaningful HTML/content
↓
HTML → Markdown
↓
clean / normalize / store
↓
Markdown → controlled HTML template
↓
nginxThat has a real advantage: instead of trying to preserve all the SharePoint-generated HTML cruft, we reduce each procedure to a simpler portable representation.
Markdown becomes our content layer.
The Python tooling can then work with something like:
# Network Outage Procedure
_Last extracted: 2026-10-06_
## Initial checks
1. Verify...
2. Contact...
3. Record...
## Escalation
| Role | Contact |
|------|---------|
| NOC | ... |Then you generate clean HTML yourself.
That buys you several things:
- much easier diffing and version control
- no dependency on SharePoint's DOM structure for presentation
- easier search/index generation
- straightforward static HTML generation
- content remains readable even without a web server
- potentially reusable later for PDFs, documentation, search, etc.
But I would not blindly convert every HTML element to Markdown.
Some SharePoint pages will contain things Markdown represents poorly, particularly complicated tables, embedded components, callouts and strange page layouts. For those, I'd allow sanitized HTML fragments inside the intermediate content rather than mutilating them in pursuit of Markdown purity.
So I'd slowly permit Markdown into the architecture like this:
HTML is the DELIVERY format.
Markdown may become the PORTABLE CONTENT format.
Python is the translator/referee.That distinction is important.
And I suspect this could actually simplify your 300-page offline project considerably. Instead of “convert 300 ASPX pages into standalone HTML,” the problem becomes:
extract the useful content from 300 pages into a stable representation, then publish it however we want.
That's a much healthier problem. 😏
Yes. For the extractor, the realistic Microsoft/O365 options are:
|
Option |
What it is |
Good fit here? |
|---|---|---|
|
Microsoft Graph API |
Direct API access to SharePoint content |
Very strong |
|
SharePoint REST API |
SharePoint’s native REST endpoint |
Very strong |
|
Microsoft Graph PowerShell |
PowerShell wrapper around Graph |
Strong, especially for a demo |
|
Power Automate cloud flow |
Microsoft-managed workflow engine |
Possible, especially if already licensed |
|
Azure Logic Apps |
More enterprise/server-side workflow automation |
Possible, but heavier |
|
Azure Function / scheduled Python |
Hosted code that performs the extraction |
Strong eventual production option |
|
CLI for Microsoft 365 |
Command-line wrapper for M365 APIs |
Useful, but only if approved |
|
PnP PowerShell |
Excellent SharePoint automation toolkit |
Technically great, but community-supported |
A couple of important licensing wrinkles:
Power Automate may already be available to you without buying Premium. SharePoint is a standard connector, and Microsoft says work/school accounts can use basic cloud flows with standard connectors under the included/free entitlement. Premium becomes relevant when you need premium/custom connectors, gateways, RPA, and similar features. Microsoft Learn
Graph itself is not generally a paid API add-on. Most normal Graph access rides on the organization's existing Microsoft 365 licensing. Microsoft separately identifies the relatively small set of Graph APIs that are metered. Ordinary SharePoint list/page retrieval isn't on that metered list. Microsoft Learn
So I'd paint your mental map like this:
EXTRACTOR OPTIONS
SharePoint Online
│
┌────────────────┼────────────────┐
│ │ │
Graph / REST Power Automate Logic Apps
│ │ │
PowerShell/Python managed flow Azure flow
│ │ │
└────────────────┴────────────────┘
↓
local destination
files / JSON / database
↓
FlaskAnd I'd put them into three buckets:
“I can prototype this myself”
Graph/REST + PowerShell or Python.
“Microsoft 365 may already provide this”
Power Automate.
“IT can productionize this properly”
Application identity + Graph/REST, Azure Function, or Logic Apps.
For where you are right now, I would investigate Graph/REST, Power Automate, and whatever Azure automation your organization already supports. Those are the three branches worth knowing about.
The key is that you are not really shopping for a product. You're discovering which approved execution/authentication model the organization already wants you to use.