Part 1 traced the system from server footprint to business function: five workflows, a shared integration spine, and six application-security review areas, all recovered from an isolated snapshot without changing the application. Part 2 follows those workflows into the database to test whether the data model supports the same story, identify control and governance risks, and show what the combined evidence means for modernization.
Everything described so far came from the application and web server. That work explained what the system does. The application server work could not explain what the business has been keeping, where that data came from, how much of the data is sensitive, or whether anyone could prove after the fact that a record had not been altered. Those answers live in the database.
We ran the database work as a separate decomposition against the snapshot of the database server virtual machine. The operating rule stayed simple: preserve the system, query metadata only, leave schema, data, permissions, jobs, configuration, and services unchanged.
The first instruction was deliberately small.
Connect to the local SQL Server, confirm the target sales distribution database exists, and make no changes.
The agent confirmed that a SQL client was available and attempted a read-only metadata query.
That query failed. The legacy command-line client could not complete encryption negotiation against this older platform. Rather than relaxing a security setting to force the connection through, the agent switched to the .NET SQL client from PowerShell, passing the credential through process memory instead of the command line, and continued with metadata-only queries. The target database was confirmed present, online and readable.
Blocked tools test the discipline of an AI-assisted engagement. We did not weaken encryption or expose credentials to force progress. We changed tools, kept credential values out of output, proved connectivity with metadata queries first, and continued without changing the database.
With connectivity established, we set the role again.
Take the role of an advanced software architect with more than thirty years of experience decomposing undocumented and unsupported systems. Analyze the schema, determine the entity relationship model, and change nothing.
The agent inventoried user tables, columns, primary keys, foreign keys, unique indexes, and row counts through catalog views. The agent then profiled likely relationships where no foreign key existed by comparing actual key values between candidate parent and child tables.
The schema measures told the story before the diagram did. 34 foreign keys across 164 tables meant the schema could not describe itself. We built the entity relationship model in evidence layers: declared constraints, measured inferred relationships, and weak candidates that were flagged or excluded. That kept the diagram useful without overstating the system's relational discipline.
The resulting model aligned with the five workflow families already found in the application: sales agreements, miscellaneous orders, partner onboarding, sales literature, and shared reference data.
That alignment made the application and database halves of the engagement visible as one system. The physical schema was messy, but the business meaning was recoverable through naming, duplicated columns, status flags, routines and integration artifacts.
The same prototype-before-scale discipline applied here. We began with one artifact set for the Sales Agreement data domain and used the Sales Agreement artifact set to agree on format before generating diagrams for every data domain. The artifact set contained a repeatable read-only export script, CSV evidence for database settings, table and column inventories, primary keys, foreign keys and their trust state, unique indexes and relationship match rates, plus a Mermaid entity relationship diagram and a Markdown readme tying the evidence together.
The export script matters as much as the diagram. Because the collection was scripted and read-only, the entire evidence base can be regenerated on demand, compared against a later snapshot, or handed to the client's own team to run themselves. A diagram is a snapshot of an opinion. A script plus its evidence files is something a client can audit.
The prototype pass also named the remaining candidate domains for follow-up work:
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.
The database analyses outlined a conceptual flow supported by schema and security evidence:
The final reorientation asked the agent to work as a senior database security analyst, review everything found so far for vulnerability indicators, and propose an outline of recommended analyses before executing any of the analyses. By this point the evidence base included the schema inventory, the layered entity relationship model, and the uncomfortable observation that a single database was holding operational data, staging data, payment data, identity data, logs and integration artifacts side by side.
Take the role of a Senior Database Security Analyst with over 30 years of experience decomposing and documenting legacy database systems. Analyze our findings so far for indicators of potential vulnerabilities in the database, presenting an outline of the detailed security analyses recommended and why. Do not make any changes.
The proposed menu ran to ten areas:
We worked through them in order, one document at a time, each backed by its own evidence file:
Proceed with the recommended analyses in sequential order, processing one at a time. Attempt to complete them all without stopping.
The findings validated the client’s own operational observations. The database evidence showed the same patterns the business had already been seeing in practice: accumulated legacy complexity, blurred boundaries between operational and supporting data, and areas where stronger governance would reduce risk during modernization. The decomposition produced evidence the client could use to confirm what they suspected and to prioritize follow-up.
The reports were also explicit about what was excluded.
The client received counts, metadata and redacted indicators, which supported action while limiting sensitive information exposure.
Each output identified its review status clearly. The documents were AI-generated and human-reviewed, and the project team marked formal validation as a later step. That distinction let the client use the materials for planning, prioritization, and discussion without confusing strong evidence with final operational validation.
The disclaimer marks the boundary between evidence, inference, review status and validation status. A model can draft a plausible synthesis from metadata and source evidence, and a human reviewer can confirm that the synthesis is reasonable and responsibly bounded. Formal validation is a later step, requiring the right business owners, technical SMEs and, where appropriate, approved runtime or data-level verification.
The engagement produced a reviewable documentation set rather than a transcript of clever prompts:
The engagement produced a repeatable operating pattern:
The database half proved the pattern travels. The nouns change from pages and services to tables and permissions, and the decomposition sequence still holds.
Disciplined decomposition turns AI speed into usable evidence.
We assembled a consolidated draft that pulled together the decomposition findings, the security integration, the appendix diagram work, and the remaining validation gaps into one coherent narrative. The draft did not replace the underlying evidence package. It turned the accumulated artifacts into a review-ready structure that a business architect, solution architect, client stakeholder, or modernization sponsor could read without following every intermediate analysis file.
The assembled draft also made the next step explicit. The static analysis had produced a strong baseline, but several open questions still require runtime validation against the development instance of the decomposed application. The recommended next action is to request a development-only username and password, the dev server URL, login instructions, representative role coverage and any testing constraints so the team can observe actual application behavior, validate inferred workflows, confirm role-specific behavior and sharpen the open questions for both business and technical stakeholders.
Formal validation comes next, with the right business owners, technical SMEs and, where appropriate, approved runtime or data-level verification. Application validation should use an approved window against a non-production copy. Database follow-up should classify payment and token data, resolve governance questions about production-scale data in a test-named database, review encryption at rest and in transit, tighten administrative role memberships, inspect job steps at the command level and model the six remaining data domains. Deeper work can add secrets scanning, dependency and CVE analysis, and access to source repositories and stored procedure definitions.
The business can act while formal follow-up work continues. The client already holds documentation good enough to prioritize remediation, scope replacement functionality and plan a modernization sequence across both the application and the data beneath the application.
The client does not need every stakeholder to read every page. The value sits in the structured evidence, open questions, diagrams, inventories, and repeatable scripts that now support validation, modernization planning, remediation, stakeholder interviews, and future AI-assisted analysis.
In approximately 45 elapsed hours and fewer than five hours at the keyboard, the team documented a platform no one could fully explain two days earlier. The resulting evidence base covered application behavior, business workflows, data structure, integrations, security indicators, and open validation questions. It gave the client a practical foundation for validating requirements, prioritizing risk, scoping replacement functionality, and planning modernization.
An experienced operator used AI to accelerate system inspection, evidence searches, cross-checking, and drafting while maintaining control of permissions, scope, sequencing, evidence standards, and stopping conditions. This approach gave the modernization team a defensible account of what exists, what remains uncertain, and what to do next.
If your organization depends on applications no one fully understands, that is not an embarrassment. It is a normal starting condition for modernization. Seabeck Systems can help you recover what those systems do, understand the data and risk beneath them, and turn that knowledge into a modernization plan you can defend.
The tool footprint stayed intentionally small and was limited to isolated server snapshots used for analysis.
AI coding agent
Directed the decomposition workflow, coordinated subagents, summarized findings, and generated draft documentation.
PowerShell
Ran local inventory, file inspection, metadata review, and controlled evidence collection commands.
IIS management surface
Confirmed application bindings, site structure, application pools, served directories, and deployment exposure indicators.
File-system inspection
Reviewed application folders, configuration files, backup files, document storage paths, binaries, debug symbols, and supporting assets.
Static source and binary review
Identified WebForms pages, ASMX services, AJAX methods, data access patterns, integration points, and potential security indicators.
Word documentation output
Converted workflow packets, security analyses, summaries, and process narratives into reviewable deliverables.
AI coding agent
Guided the database decomposition, proposed analysis menus, generated scripts, interpreted metadata, and drafted database security findings.
PowerShell with .NET SQL client
Connected to the local SQL Server instance after the legacy command line client could not complete encryption negotiation.
SQL Server catalog views
Collected metadata for databases, tables, columns, primary keys, foreign keys, indexes, permissions, roles, jobs, modules, and configuration.
Read-only export scripts
Generated repeatable CSV evidence without changing schema, data, permissions, jobs, configuration, or services.
Relationship profiling queries
Compared candidate parent and child key values to identify inferred relationships where declared foreign keys were missing.
Mermaid diagrams
Rendered layered entity relationship views that separated declared, inferred, and weak candidate relationships.
Redacted evidence files
Preserved counts, metadata, and indicators while excluding raw personal data, tokens, password hashes, full job commands, and full procedure definitions.
