Taking over a system nobody documented
The people who wrote it have left, and nobody can promise that changing one thing won't break another. Rather than guessing, scan it once and lay out what is in there, what calls what, and where the risk sits.
Four situations, one problem
You built it, and the author left
The system was written and maintained in-house, the developer left a few years ago, and the handover was one document. Changing a single field now comes with nobody able to promise nothing else breaks.
Outsourced build, vendor long gone
The system was contracted out, closed on acceptance, and the original vendor has changed hands or no longer takes the work. All you have is a copy of the source and no idea what is inside it.
A client handed it to you to maintain
Consultancies and dev shops inherit a client's existing system and have to answer "can it be changed, and how long will it take" before quoting — with nothing but manual code reading to go on.
You won the tender and inherited the last build
After winning the contract you pick up whatever the previous supplier left behind, and both handover and acceptance need something in writing. Anecdotal experience is not something a client will sign off.
What you have in hand after day one
Not "risk appears elevated" — things you can take into a meeting and point at a file with.
What this system actually looks like
Class diagrams, package diagrams, component diagrams, call graphs, dependency graphs, data-flow diagrams, sequence diagrams, deployment diagrams — 20 types in all, generated straight from the code. Filter by role (systems analysis, systems design, development, database administration, interface design, project management, compliance, leadership — nine in total) so you don't have to read all of them at once.
What is wrong, and on which line
All 31 frameworks are evaluated in the same scan, and every finding points at a specific file and line, ranked by risk. That list is what you estimate effort and set priorities from.
Which packages it uses, and what's lurking
The SBOM lists every dependency, its licence terms and its known vulnerabilities, exported as CycloneDX and SPDX. Find out about licence problems or unmaintained packages before you take the system on, not after.
Overall health — and which axes are estimated
The eight-axis risk fingerprint: security posture is measured by the scan. Documentation, testing, dependencies and technical debt are currently system defaults, labelled (est.) on the chart and never surfaced as risk findings. We would rather label them than hand you a chart that looks fuller than it is.
The human side
The risk assessment questionnaire covers what a scan cannot see: system handover, requirements traceability, change prediction, acceptance criteria and communication cost. Those scores come from what your team answers, not from scanning code.
You own the reports and everything they produce. Hand them straight to a client or to management as an attachment for handover, acceptance or a quote.
What it can read
This is usually the first question, so here it is plainly. Analysis comes in two layers: the .NET family gets a syntax tree plus compliance and security rules; the other 62 technology families get syntactic parsing and call relationships, but not those rules.
Deep analysis (syntax-tree level)
C#, VB.NET and ASP.NET WebForms (.aspx plus code-behind). Class inheritance and dependencies, API endpoints, data flow, business logic and error handling are all parsed at this level.
Files the compliance rules scan
.cs, .vb, .aspx, .sql, .config, .json, .xml, .yml, .yaml, .ps1, .sh, .tf, plus .md and .txt documents. The findings list for the original 24 frameworks comes from these files; the seven AI governance frameworks look separately at AI use across all supported languages. Extensions such as .cbl, .pas, .pbl, .prg and .abap are not on the list, so a hardcoded password or SQL injection pattern inside legacy-language source will not appear in the findings — that layer covers structure and call relationships instead.
Syntactic parsing and call relationships (62 technology families)
Java, Python 2/3, PHP 5/7/8, Go, Rust, C++, SAP ABAP, PowerBuilder, VB6, COBOL (85/2002/IBM/Micro Focus/GnuCOBOL), Delphi, FoxPro, Fortran, Pro*C, classic ASP (VBScript/JScript), AngularJS, jQuery, Ember, TypeScript, CoffeeScript, Blazor, Flutter, MAUI, Xamarin, Flash/Flex, Silverlight, and .NET DLLs with no source (inventoried after decompilation). This layer does more than count files: it extracts programs, classes and procedures, builds the call graph of what invokes what, records the number of conditionals, loops and exception handlers in each routine, and flags dynamic call sites — the places where the target is only decided at runtime, which is exactly what migrations miss. COBOL additionally expands copybooks (including REPLACING) and identifies the dialect. These results merge into the same inventory as the .NET layer, so the diagrams and impact analysis cover them too.
Where the code comes from
A Git repository URL (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea and others; self-hosted Git servers on an internal network have to be allowed in the settings), or a ZIP upload of up to 2 GB per submission. No CI and no pull-request workflow is fine — zip the folder and it can be scanned.
This layer requires Python on the analysis engine (Agent) host; each technology family can be switched on or off individually.
Not supported today
TFVC and SVN cannot be connected directly (upload a ZIP instead), Oracle PL/SQL packages, Excel VBA macros, and PLC or OT controller programs. Better you know now than halfway through a scan.
If you want to replace the old stack
The stack migration module starts with an assessment: what the system runs on today, how many phases the move takes, and which files each phase touches. Automated conversion (codemods) is currently .NET-focused — WebForms to Razor, EF6 to EF Core, .NET Framework to .NET 9. Other languages get the assessment and the before-and-after compliance comparison, with the conversion itself still done by your team.
- Compliance state before and after, side by side — evidence that the upgrade did not weaken security
- Every phase's output stays in the document centre, downloadable and traceable
- Conversion results can be opened straight as a pull request (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea)
Start by scanning one project
The free tier is free forever: 1 seat, 3 analyses a month, online viewing of the full report and scores. Online self-service sign-up is not open yet, so contact us first if you want to see real results. If your code cannot leave the network, talk to us about running it inside your own environment.