Reverse-engineering a 15-year-old document automation system before replacing it
Nobody left at the firm understood the 15-year-old macro system that assembled its core documents, and the person who built it was long gone. Reverse-engineering roughly 20,000 lines of undocumented code fast enough to matter meant living by one rule: label every claim as inferred or verified, and log every reversal instead of quietly fixing it. That rule caught a wrong assumption a person, not a document, ended up correcting.
Category
Legacy system forensics ahead of a platform migration.
What I was trying to accomplish
Understand exactly what a 15-year-old, undocumented Word macro and template system actually did, fast, before anyone could scope replacing it, without the person who originally built it.
The data challenges
About 20,000 lines of undocumented VBA, a large template package library, and a 600-entry master document index, under a strict rule that every inference be labeled inferred versus verified, with every reversal logged and explained rather than quietly overwritten.
The result
A small, deliberately capped knowledge base, a redacted edition safe to hand an outside consulting firm, and nine logged reversals, each with its reason on record. One early assumption about the system turned out wrong and was only caught because a person supplied context no document contained.
Technical details
Tools: claude.ai Projects, Microsoft 365 connector, Python (oletools)
One of the firm's practice groups assembled its core documents with a Word macro and template system built around 2010. It still worked, but nobody in-house could maintain it, and the firm was evaluating a move to a modern no-code document-assembly platform.
The inputs were the firm's global macro template, extracted with oletools, the library of template packages that held the assembly logic, the practice group's master document index of roughly 600 entries, and one blank sample package parsed down to its individual fields. It ran as a claude.ai Project with a deliberately small knowledge base: eight numbered files, capped so the re-upload-after-every-change step would not break down. The project rules were strict: read before writing, label anything inferred versus verified, and record every reversal in the changelog with its reason instead of quietly overwriting.
The outputs were the knowledge base, a separate index analysis, and a redacted edition prepared for an outside consulting firm, with names, internal system identifiers, and internal-only commentary replaced with bracketed category tags. The challenges shaped the method: text extraction from the index inserted spaces inside document ID numbers, so every number used as a lookup key had to be re-verified against the raw binary, and an early assumption about where the macro engine was installed was wrong. The initiative was put on hold for a firm-level decision before a full-library parse, with that next step specified and ready.
Pull up a chair.
Let's talk through where things stand, and where they could go.