The most surprising thing about an ERP migration isn't the software that changes. It's what the wiki documenting it becomes, while the migration is in progress.
Open this wiki and you meet two projects at once. The first is an ERP migration: a fashion retailer, with a few thousand SKUs per season, is dropping its legacy ERP for a modern cloud platform, while around it orbit a frontend-online satellite system, a third-party operations suite, a sales CRM, a couple of vertical product applications, and a BI layer. The second project is the wiki itself: several hundred pages in a knowledge management tool, documenting that transition through dozens of decisions, problems, open questions, meeting notes, people, modules, glossary entries. The two projects aren't independent: the way the wiki is built reflects the way the migration is being done, an iterative assembly of partial pieces trying to hold a system-world together.
The system-world before the switch
The meeting notes cover a span of several months and describe a company that runs on fragile document flows. Goods arrive without the right delivery note, a proforma invoice gets cancelled and distorts the historical record in BI reporting, the bank details in the order confirmation template are out of date, buyer master data arrives incomplete. On the logistics side the complexity is artisanal: returns from photo shoots with no automation, central warehouse and store warehouse with priorities to balance by hand, store-driven and online-driven brands that need different order criteria but impose them on the same software. On the commercial side, B2B coexists with marketplaces, direct retail, and accessory channels. One ERP, too many operating models.
The people hold all of this together by hand. The project graph picks out a small group of reference figures, a project sponsor on the management side, an operations lead, a controller, a few function heads in buying and logistics, not by hierarchy but by centrality in decisions: they are the nodes where most decisions and problems converge. The migration, read this way, is an attempt to transfer from people to systems the knowledge that today lives in heads.
The pipeline that rebuilds the system-world
This is why the wiki couldn't be written by hand. The architecture is the one from Karpathy's LLM wiki: not RAG over raw documents at query-time, but an LLM that builds and maintains a persistent, interconnected base of pages, source after source. Under the scripts folder lives an ingest pipeline that turns raw meeting notes into structured pages: a hash on each source feeds a manifest with delta tracking, a document converter normalises into Markdown, and a parallel LLM extraction (multiple workers, one call per entity type) produces people, decisions, problems, modules, and questions with their frontmatter. The most interesting piece is the matching function: an accent-aware normalisation recognises that "Mario" and "Mario Rossi" might be the same person, returns exact match, partial, or none, and lets the merge step decide whether to enrich an existing page or create a new one. The merge of frontmatter and lists is idempotent: the pipeline can be re-run without creating duplicates or losing manual annotations.
The parallel is obvious. The pipeline does for meeting notes what the new ERP will have to do for company flows: take semi-structured information, deduplicate it against an existing master, integrate it without destroying what has been curated by hand. Even the "no documents, no receiving" principle, which the meetings adopted for incoming goods, has its technical twin in the wiki schema: no frontmatter field is optional by accident, every entity must declare type, status, date, related.
Merge idempotence is a property many Italian operations packages lack: re-running a file import produces duplicates instead of clean updates. That is exactly the technical debt the migration is trying to dump into the new system. The wiki, meanwhile, has already dumped it.
The decisions that hold together
The decisions piled up in the vault aren't independent: the knowledge graph shows they converge on three axes. The first is payments and credit: pre-shipment policy for B2B with credit insurance coverage assessment, deposits and down payments tied to order confirmation, automatic alerts on expired proformas, cross-checks on marketplace invoicing. The second is traceability and status: a single operational status schema in the ERP, the proforma flow generated from the package, booking of incoming goods with mandatory documents. The third is governed automation: adoption of AI for virtual try-on but with systematic manual control, evaluation of tools for automatic product code matching, availability alerts toward logistics receiving.
The most connected god node in the graph is a single mid-project meeting, with over fifty edges converging on it. It's the moment when the three axes enter the same room: order confirmations, payment traceability, customer reporting, B2B roadmap. It's no accident that it sits near the end of the time sequence covered: it's the meeting where decisions taken in the previous months are finally operationalised.
The surprises the graph reveals
Here the doubleness of the project pays its dividend. Read as text, the wiki tells the story of the migration. Read as a graph (a few thousand nodes, almost ten thousand edges, more than 90% of edges extracted directly from the documents rather than inferred), it reveals things that no one, reading the meeting notes one by one, would see.
Three examples. First: two person-nodes, "Mario" and "Mario (CRM)", show up as distinct, linked by an edge marked AMBIGUOUS: the dedupe isn't closed yet, and the graph says so before anyone notices it re-reading the notes. Second: an INFERRED edge between "deposits/down payments and payment traceability" and "adjustment of marketplace invoicing flows with cross-checks" shows that two decisions born in different meetings are solving the same structural problem: reconciliation between order, payment, and invoicing through a third channel. Third: the "proforma" node is connected to the problem "cancelling a proforma alters historical availability in the BI tool" by an inferred edge that no meeting note ever stated explicitly. It's a graph inference, but it's correct: changing the proforma flow will change the BI downstream, and that needs to go into the plan.
There is also a hyperedge, a group of nodes that participate together in a pattern, labelled "buyer operational flow / order loading". The graph recognised that some entities scattered across different folders of the wiki actually form a single operational process. It's exactly the kind of evidence that feeds the next phase of the project: figuring out where the refactor on the new ERP can consolidate, not just replicate.
What stays open
The questions in the questions/ folder are the open work front: how the ERP automatically routes thousands of order lines to the right screen, where goods that change destination after being picked from the warehouse get parked, which responsibilities are assigned to the internal project manager of the migration and which aren't. The graph, in its current state, still mixes signal and noise: a good share of the communities are plugin code from the documentation tool, to be excluded with an ignore rule. The ingest pipeline has already passed a reusability test on a completely different domain (a software development standup, with all assertions passed), which hints at a future in which this same infrastructure serves not just this migration but the next ones.
The conclusion that holds for both projects is the same. An ERP migration isn't the move from one piece of software to another, and that is why it needs a wiki: it's the move from the tacit knowledge of people to an explicit model the system can execute. The wiki is the lab where that model gets articulated, and the knowledge graph is the tool you use to check that its parts hold together. When go-live day comes and the new ERP replaces the legacy one, what will really have been migrated isn't the software: it's what this wiki is, today, learning how to say.
If this resonates with a migration you're planning, write to me: andrea.iorio@me.com. Conversations usually start from a meeting note no one can interpret any more.