Hi everyone!
I am designing an automated migration pipeline to transition a large set of internal documentation, wikis, forum discussions, and media attachments from a legacy enterprise social platform into an enterprise Confluence-based wiki system.
Our goal is content restoration, ensuring the structure, body content, attachments, formatting, and historical metadata remain as it is. We plan to build a GitHub Copilot Agent to assist with semantic restructuring and transformation.
I would love to get the community’s insights on the best architectural approach, metadata preservation techniques, and Copilot Agent design for this task.
Source Platform
│
▼
API Extractor
(Downloads raw JSON/XML, metadata, and attachments)
│
▼
GitHub Copilot Agent
(Transforms HTML/XML into Confluence Storage Format, converts supported elements, rewrites internal links, and prepares upload manifests)
│
▼
Human Review
(Validates hierarchy, formatting, and generated previews)
│
▼
REST API Publisher
(Creates pages, uploads attachments, and reconstructs the page hierarchy in Confluence)
The source platform contains nested communities, wiki pages, forum discussions, and attachments, whereas the target is a Confluence Space with a strict page hierarchy.
What is the recommended strategy for reliably reconstructing deep parent-child relationships during upload? Is a top-down recursive creation approach generally preferred, or are there more robust patterns for large migrations?
Since all pages will be created through a single REST API migration account, the original creator and timestamps cannot be retained as native Confluence authors.
What is the recommended approach for preserving original author, creation date, last modified date, source URL/ID)? Is it common to use a standard metadata banner, page properties, or another pattern?
For anyone building GitHub Copilot or LLM-based document transformation pipelines, what structured schemas have worked well to preserve technical content, code blocks, tables, and formatting?