Your organization may depend on a system nobody fully understands anymore. The people who shaped it may have moved on, the vendor may be gone, and the documentation may describe a version of the business that no longer exists. Fortunately, a legacy system is not unknowable. If your organization operates a critical system in this state, your first modernization step is not replacement. It is disciplined decomposition.
This two-part field note explains how Seabeck Systems approached that challenge for a client with an undocumented, unsupported legacy manufacturing and sales distribution platform. Part 1 focuses on the application and the business workflows it supported. Part 2 focuses on the database, the security evidence, and the controls that kept the decomp work safe, bounded, and useful.
AI-assisted decomposition can produce reviewable evidence about an undocumented legacy system within days, giving modernization teams a factual basis for decisions.
By the end of this field report, you will have a practical sequence for decomposing an undocumented legacy platform without disturbing production: establish permission and scope, work from isolated snapshots, inventory before interpreting, translate technical evidence into business workflows, prototype deliverables before scaling, and distinguish evidence from inference and formal validation. You will also see how application and database findings can be combined into usable documentation, security priorities, and next-step questions that support a defensible modernization plan.
Seabeck Systems delivered a usable modernization foundation: five business workflow packets, a system integration view, application security findings, a layered entity relationship model, database security analysis, redacted evidence files, and repeatable scripts that the client’s team can rerun or review.
The AI agent accelerated reading, searching, cross-checking, and drafting. Human judgment controlled scope, sequence, interpretation, and client-facing use. That balance turns AI speed into defensible results.
Modernization programs often stall for the same reason. No project sponsor, business owner, or technical lead can say with confidence what the old system actually does. The original developers have moved on, the vendor no longer supports the platform, and any surviving documentation, if documentation ever existed, describes a version that shipped a decade ago. Teams then face a choice between guessing at requirements or spending a year and a large budget rediscovering system behavior by hand.
Legacy decomposition removes that guesswork. Legacy decomposition is the disciplined work of recovering what a system does, who uses the system, what data the system touches, and where the business risk lives. Applying AI to decomposition work compresses the timeline dramatically. Instead of months of interviews and code reading before the first real decision, a client can hold reviewable business documentation in days and start making modernization decisions on evidence rather than memory.
Total elapsed effort
Approximately 45 hours to set up and complete the decomposition analysis described in this document.
Human hands-on time
Less than 5 total hours at the keyboard.
Before any analysis began, we asked for and received written permission to apply AI tooling to the systems in scope. The client agreed readily. Every application on the list had been abandoned by its original vendor and none of them are sold or supported today.
Seabeck Systems defined the purpose clearly: decomposition (not reproduction) of vendor-owned software. We recovered the business functionality the client had funded, specified, and customized on top of a dead vendor platform so the client could understand, validate, and rebuild that functionality around the way the business runs today. The client owns the workflows. Decomposition gives the client system documentation those workflows never had.
This client had already lifted and shifted the target application into Microsoft Azure, running on virtual machines. That made the next decision easy. We took snapshots of both the application and web server virtual machine and the database server virtual machine, then used those snapshots as our working ground for the entire decomposition.
Working from snapshots is not a formality. The snapshot approach means no analysis activity can touch production, no read can lock a table that a shipping clerk needs, and no experiment can leave a mark on a system the business still depends on every day. Snapshot-based analysis also gives the analyst room to be curious without asking permission for every step.
For readers who want the implementation detail, all analysis took place on isolated virtual machines created from Azure snapshots of the application / web server and database server virtual machines. Creating those snapshots did not require installing analysis tools inside the servers. Any tools added afterward were installed only on the isolated working copies and limited to what the analysis required.
That distinction matters. The snapshots preserved the server state at the time of capture; minimizing additional tooling limited drift from that baseline, reduced the possibility of interfering with the application, and made the resulting evidence easier to trust and reproduce. The full tool inventory appears in the appendix.
The practical rule was simple: work from snapshots, keep generated materials in a controlled workspace separate from the application, document gaps instead of weakening controls, and leave production systems and business data untouched.
The opening instruction to the agent did most of the heavy lifting for the rest of the engagement. The instruction is reproduced verbatim below:
Take the role of an advanced software architect with 30+ years of experience decomposing existing, undocumented, and unsupported legacy software systems. Use two or more subagents to analyze this local host so we can understand more about its features, functions, and software that are outside of a normal Windows installation. Begin with a high-level catalog so we can choose where to focus. Do not make any changes.
Four sentences carry five decisions:
The first pass produced a catalog that separated the normal Windows baseline from the business-relevant footprint:
Within the first pass we knew what we were dealing with. The system of interest was a legacy sales portal hosted under IIS, built on ASP.NET WebForms with an ASMX web service layer, supporting product ordering, partner onboarding, compliance documents, replacement parts, and sales literature.
This is the habit that keeps an AI-assisted decomposition from sprawling. After every major pass, we asked the agent to convert what it had found into a short list of numbered options for the next pass. The first menu offered six directions:
We worked through the six menu options incrementally, using the following prompt:
Proceed with the recommended analyses in sequential order, processing one at a time. Attempt to complete them all without stopping.
That sequence let each analysis pass stay bounded while still building on the findings from the prior pass.
Technical inventory answers the question of what is installed. The client needed an answer to a different question, which is “what does the application actually do for the business?” So we changed the frame explicitly and told the agent we were now working alongside a senior business systems analyst, and that we wanted an overview system interaction view followed by analysis from a business functionality perspective.
Now let us reorient our goals. We are working closely with a Senior Business Systems Analyst with over 30 years of experience decomposing and documenting legacy software applications, who is helping us document the business functions of the software you found. We want an overview system interaction diagram, and then we want to analyze the application from a business-functionality perspective. Do not make any changes.
Naming the stakeholder role changed what mattered. Business meaning, workflow boundaries, and documentation format moved ahead of raw code inventory. The application resolved into five workflow families:
We began with one prototype: the Sales Agreement workflow.
That workflow became the prototype because the Sales Agreement workflow was central to the business, integration-heavy and representative of the application's complexity. Once we agreed that the packet had the right level of detail, organization and tone, the same structure could be reused for the remaining workflows without repeating the format discussion.
We converted that packet to Word, reviewed it, and only then asked for the remaining four in the same format. No format negotiation was needed a second time, and neither was the rework that usually follows a big documentation push.
We then used the same incremental approach for the business analysis menu options that we used for the technical menu options.
Proceed with the remaining recommended analyses in sequential order, processing one at a time and keeping the same format and output categories that are found in the Sales Agreement workflow documentation. Attempt to complete them all without stopping.
Five well-documented workflows are still five isolated documents until somebody draws the lines between the workflows. We used the following prompt to build an integration diagram:
Build a system integration diagram that supports all five business workflows.
The integration diagram made the shared spine visible. Users authenticate through the login layer and land on a role-specific menu. Menu choices route into one of the five workflows. Workflow pages call static AJAX methods and ASMX services. Those methods call the compiled business and data layer, which in turn reaches databases, document folders and network shares, the external order management platform, the payment gateway and email and notification paths.
Shared dependencies, coupling points and concentrated risk all showed up in that single integration view. The integration view is also the artifact a modernization roadmap is built on, because the integration view shows what can be carved off first and what has to move together.
With the architecture and business views in hand, we changed roles again and asked the agent to work as a senior application security analyst, reviewing everything already found for vulnerability indicators and proposing an outline of recommended analyses with reasoning. The security phase reused the accumulated application evidence base instead of starting a fresh scan from zero.
Take the role of a Senior Application Security Analyst with over 30 years of experience decomposing and documenting legacy software applications and analyze our findings so far for indicators of potential vulnerabilities in the analyzed applications, presenting an outline of the detailed security analyses recommended and why.
We used the following prompt to produce a Word document for each of the six areas of vulnerability.
Proceed with the recommended analyses in sequential order, processing one at a time. Attempt to complete them all without stopping.
Two bounded parallel analysis agents cross-checked the findings while the primary agent retained responsibility for coordination and final synthesis. We preserved production systems, avoided exploit probes, avoided test uploads, avoided payment calls, avoided database changes, and left IIS and the application unchanged. We redacted every secret value before sharing the final documentation.
By the end of the application server work, the team had moved from an unknown application footprint to a reviewable account of the system's architecture, five business workflows, their shared integrations, and six security review areas. Just as important, the method established a repeatable cadence: catalog broadly, choose a bounded next step, prototype one deliverable, scale only after review, and preserve the system throughout.
The application view answered how the platform behaved, but it could not yet show whether the database supported those same boundaries - or where undeclared relationships, sensitive data, and control gaps might change the modernization sequence. Part 2 follows that evidence into the data layer, then brings both halves together into a reusable playbook and a practical set of next steps.
