Confluence wiki migration
Rewrote a 2021 Confluence-to-SharePoint migration tool that Microsoft's platform changes had broken, rebuilt the navigation the migrated wikis depend on, and re-ran the migration across four intranet wikis: 697 pages and 341 diagrams that are still editable.
- pages across four wikis
- 697
- draw.io diagrams, still editable
- 341
What it is
In 2021 three colleagues built a PowerShell tool that moved Confluence spaces onto SharePoint, with a custom navigation extension that turns each migrated wiki into something you can find your way around. In 2025 Microsoft changed two things underneath it. The shared sign-in the scripts used was retired, so the tool could no longer connect at all. And the modern page shell stopped exposing the page elements the navigation mounted into, so every wiki already migrated lost its menu at once.
A broken tool and a set of wikis nobody could navigate became mine to fix, and then the migration had to be done again, site by site.
What I did
I replaced the main migration script with a new one. It resumes where a killed run stopped, parses page HTML with a real parser instead of leaking COM objects, carries draw.io diagrams across as editable web parts rather than flattened images, fixes pages whose parts were assembled in reverse, transliterates Polish characters in titles and URLs, and keeps version history instead of flattening it. Every supporting script was rewritten for app-registered, MFA-capable sign-in and for a Confluence API that now throttles bulk reads: retries, back-off, and a written list of anything that could not be recovered instead of a silent gap.
I rebuilt the navigation extension onto the supported placeholder API, with bounded retries and re-mounting on client-side navigation, and fixed a site-matching bug that served one wiki the menu of another. Then I wrote the runbook the original never had, so the fourth site did not need the person who wrote the tool.
A decision and its cost
The first thing the new script got was resume, before any of the content fixes. A migration you cannot restart is one you cannot debug: every attempt to fix a bug on page 400 costs you pages 1 to 399 again, and against a rate-limited source that is hours. The extract-then-import split came from the same reasoning, and the later legal knowledge-base migration reused it on purpose.
Counting the result on the live sites, rather than trusting the script's own logs, shows why the diagram handling mattered: nearly half the pages carry one. It also shows a real gap: on one site, six diagrams on four pages never converted, all of them second or later diagrams on pages that had several. A page missing one of its two diagrams looks fine in a browser; it shows up only in a count.
Related
Legal knowledge-base migration
Moved a legal department's 1,029 knowledge articles, with attachments, images, topics and per-article permissions, out of a retiring helpdesk product into SharePoint.
1,029 of 1,029 articles migrated
Case study Sole author
Python 3.12 · Microsoft Graph · MSAL · SharePoint Online
Shared navigation extension
One data-driven intranet menu, deployed once and served from configured entries, that site owners maintain themselves.
Project Principal developer since 2022
SharePoint Framework · React · TypeScript · PnPjs