Chapters: 

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
      ↓
nginx

That 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
                         ↓
                       Flask

And 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.