Was ist die XITASO Software Modernisation Suite?

Eine Reihe KI-gestützter Komponenten, die XITASO-Software-Engineers einsetzen, um geschäftskritische Legacy-Software zu modernisieren. Sie verbindet menschengeführtes Requirements- und Geschäftsprozess-Engineering mit KI-Beschleunigung innerhalb eines technischen Harness, das Korrektheit, Architekturkonformität und Verifizierbarkeit sicherstellt.

Für welche Unternehmen ist die Suite gedacht?

Für Unternehmen mit geschäftskritischen Systemen in veralteten oder eingestellten Technologien (z.B. .NET Framework, AngularJS, WinForms, Legacy-SPS-Systeme), insbesondere dort, wo Dokumentation dünn ist und Schlüsselexperten kurz vor der Rente stehen.

Wie verhindert die Suite technische Schulden 2.0?

Durch zwei Mechanismen: ein Harness aus Architekturregeln, Fitness Functions/CI-Gates, statischer Analyse und KI-generierten Charakterisierungs- und Differenztests, innerhalb dessen die KI arbeitet; sowie KI-gebaute, deterministische Tools für datenbasierte Entscheidungen. So bleibt KI-Geschwindigkeit korrekt und architekturkonform.

Wie viel schneller macht KI die Modernisierung?

Auf realen Kundenprojekten wurden für mechanische, gut abgegrenzte Aufgaben (Reverse Engineering, Migration, Testerstellung, Security-Triage) Beschleunigungen von 5–15× gemessen. Urteilslastige Arbeit wie Architekturentscheidungen wird nicht gleichermaßen beschleunigt; das Assessment misst, wie viel Ihres Codes in die beschleunigbare Kategorie fällt.

Funktioniert die Requirements-Analyse auch ohne Zugang zum Quellcode?

Ja. Wo der Zugang zum Quellcode eingeschränkt ist, kann die Requirements- und Prozessrekonstruktion dennoch durchgeführt werden – ein Ansatz, den XITASO in einem peer-reviewten Paper dokumentiert hat.

Wie startet ein Projekt mit der Software Modernisation Suite?

Mit einem kostenlosen 45-minütigen Scoping-Call und anschließend einem Assessment zum Festpreis, das Zielarchitektur, Renovate/Renew/Replace-Entscheidungen, Roadmap, Aufwandsschätzung und einen in Ihrer Codebasis verankerten Business Case liefert.

Software Modernisation Suite

Software Evolution — Modernisation + Innovation: AI-accelerated, expert-led.

Legacy software is not an IT problem — it is an innovation and business risk. XITASO’s Software Modernisation Suite uses AI to accelerate the slow, expensive parts of modernisation — our software engineers make sure faster also means right.

At a glance:

The problem: ~70% of IT budget goes into keeping legacy systems alive. The hardest part is rarely the code, but reconstructing what the system does for the business and how it is actually used – once documentation and the original developers are gone.
Our mechanism: proven, human-led requirements and business-process engineering, augmented by AI that compresses understanding and migration (5–15×) – executed inside an engineering Harness with deterministic tooling.
The result: a modernised, well-understood base for new features and business models – modernise first, then innovate on top.
Who it’s for: business-critical systems in outdated/discontinued technologies (e.g. .NET Framework, AngularJS, WinForms, legacy PLC systems) – especially where documentation is thin and key experts are near retirement.

Our offer: from a fixed-scope assessment to innovation

Step 1 · Recommended entry point

Modernisation Assessment

“Should you modernise, and how?” Fixed price · fixed scope · low risk

A fixed-scope, time-boxed engagement that inventories your system, applies the relevant discovery capabilities, and delivers a clear, evidence-based recommendation before you commit to a modernisation budget.

Duration

typically 2–4 weeks, depending on system size and number of repositories (confirmed in the scoping call).

Deliverables

reconstructed architecture snapshot
requirements overview, documented business processes (BPMN) and domain stories
quality and security findings
risk register
an extensible target architecture with the quality goals that drive it
per-component Renovate/Renew/Replace decision matrix
milestone roadmap
effort estimate and a business case grounded in your codebase.

Prerequisites

access to source repositories and available documentation; roughly 2–4 subject-matter experts for a few hours each across interviews and validation sessions (low operational disruption); a nominated technical and business point of contact. (Where source-code access is restricted, we can still run the requirements-and-process reconstruction, as we have done before [3].)

Commercials

Fixed price, fixed scope. Because the Assessment is time-boxed to a small expert team over 2–4 weeks, its cost tracks a predictable band — driven mainly by system size and complexity — rather than an open-ended discovery bill. The exact price and scope are fixed in a free scoping call.

Decision criteria you leave with

a defensible go/no-go on modernisation (including “don’t — retire or buy standard software” if that is the honest answer), the recommended pattern (iterative vs. big bang), the first slice to tackle, and the expected business case.

Step 2

Modernise iteratively to reduce risk

The Assessment ends with a costed, milestone-based roadmap, so the full engagement is transparent from the start:

Delivery model

milestone-based delivery per component/slice (Strangler Fig by default). Each slice is scoped, estimated, and shipped as a validated, running increment. Each increment is validated individually to contain risk and to create clean points to pause at.

Commercials

capped time-and-materials.

Team

an XITASO expert-led squad working with your subject-matter experts.

Governance

a regular steering cadence with your technical and business leads, architecture-board touchpoints at each Renovate/Renew/Replace decision, and an explicit risk-acceptance step before every production cutover.

Step 3 · Optional

Innovation on the modernised base

Modernisation is the foundation for what comes next. Once a stable, secure base is in place (built on the target architecture defined in the Assessment), the same expert-led, AI-accelerated teams can add the new features, channels, and business models the legacy system blocked, now on an architecture designed to support them. Common examples:

A new front-end or interface

a mobile or web front-end, or a public API, on top of what used to be a desktop-only or terminal-bound application.

Analytics and reporting

dashboards and reporting on data that was previously locked in forms and spreadsheets, and from there the AI/ML use cases the old stack could not host.

New revenue and delivery models

cloud or SaaS delivery (e.g. of predictive-maintenance capabilities), self-service portals for customers or suppliers, and integrations with partner systems.

Efficiency gains

automating the manual workarounds the requirements work uncovered.

Unlock access

Get full, free access to the Software Modernisation Suite

All seven suite components, the 4-phase methodology, and the three highest-stakes mechanisms in detail — free of charge, unlocked after a short registration.

Access to all suite content is free of charge. The Modernisation Assessment presented within it is a separate, paid offering.

Name *

Company *

Business email *

Phone

I consent to the data I provide being processed to deliver the content. I understand that XITASO may contact me using the data provided. I can withdraw this consent at any time, e.g. by email to info@xitaso.com. Further information in our privacy policy.

Preview mode: without a connected Contact Form 7 form, the content is shown directly for testing purposes. Once the CF7 shortcode is inserted above, the content is only unlocked after a successful submission.

Unlocked content

Why software modernisation is on the agenda right now

For many companies, software modernisation is being forced onto the agenda out of sheer necessity:

62% of companies say parts of their business-critical applications are already too outdated to meet today’s requirements; 76% expect at least a fifth of their core applications to need modernisation within five years. [1]

Only ~30% of IT budget reaches innovation; ~70% is consumed just keeping the lights on. [2]

[1] Lünendonk & Hossenfelder, “IT-Modernisierung zwischen Legacy, Cloud und KI,” Lünendonk-Studie 2026. [2] VDMA, IT-Kosten-Benchmark 2025.

Behind those numbers is a pattern our clients describe again and again:

Documentation is missing or outdated, and the underlying business processes are unclear; in one real case, an organization did not even know whether a system was still business-critical.
The people who understand the system are approaching retirement. Decades of knowledge is about to leave the company, and with it the base from which people or AI could inherit that knowledge.
Nobody has a current picture of how the software is really used: which roles do what, which workflows depend on it, and which manual workarounds have grown up around its gaps.
Outdated technology (e.g. .NET Framework, AngularJS, WinForms on old Windows) blocks new use cases, raises the cost of every new feature, and creates vendor lock-in.
Large codebases hide unknown edge cases, and regression tests are missing, so no one dares touch anything.

The result: the business cannot react to market changes and new requirements in time, the development of new business models is held back, and new technology like AI cannot be integrated into the existing systems. IT stops being an innovation driver and becomes a brake.

The business case: freed budget, cheaper features, contained risk

The suite addresses the most expensive problem in legacy work (safely understanding a system well enough to change it) and compresses it with AI under engineering control. That translates into board-level outcomes:

Freed operating budget. Every task AI compresses (reverse engineering, migration, test creation, security triage) is effort that no longer has to be paid out of the ~70% “keep-the-lights-on” budget.
Cheaper features, for years. Reconstructed requirements, documented business processes, a domain glossary, and a regression-test safety net are durable assets. Every future feature is faster and less risky because they exist.
Faster time-to-market. Compressing multi-week analysis and migration tasks is the difference between a modernisation measured in quarters and one measured in years.
Risk reduced as you go. We deliver continuously in validated increments, so value is realized along the way, rather than gambled on a multi-year rewrite, the most common way modernisation budgets are lost.
A foundation for innovation. A stable, well-understood base is the precondition for the new features and business models the legacy system blocked. Modernisation is therefore the basis those later steps build on, not the goal in itself.

We quantify these numbers for your system in the Assessment, so the business case rests on your codebase, not our averages.

For a mid-sized system where a full rewrite was estimated at 24 months, an assessment-first, sliced approach typically lets a client:

ship the first production-safe modernised slice as early as the first quarter, rather than only at the end of the program;
tackle each subsequent slice only once the previous one is functional and live, keeping risk and exposure contained;
stop at a stable, secure base if the business case for further innovation isn’t there.

How the economics move: take a program with an analysis/migration workload of, say, 2,000 engineer-days. AI does not accelerate all of it evenly: the mechanical, well-tested portions (a substantial fraction) compress at the 5–15× we observe on real tasks, while judgement-heavy work (e.g. architecture decisions, requirements validation) does not. Even if only ~40% of the workload is the kind of mechanical, well-bounded work AI accelerates well, and it compresses ~8×, that part drops from ~800 to ~100 days: the program’s analysis/migration effort falls by roughly a third. The Assessment’s job is to measure how much of your code falls into that category, so this becomes a real number rather than an average.

The core principle: AI for speed — engineering for correctness

AI without an engineering foundation creates technical debt, just faster. A model that generates code with no guardrails ships “technical debt 2.0” at machine speed. Our method is built to prevent that by never letting the AI’s unconstrained output be the thing you depend on. Two mechanisms do the work:

The Harness — the engineering quality framework inside which the AI is allowed to generate and change code. Concretely, the Harness consists of, among other things: architecture rules and dependency constraints enforced as fitness functions / CI gates; static analysis and quality thresholds that fail the build on violation; AI-generated characterisation and differential tests (see below) as the regression net; and defined acceptance criteria plus human review for every generated slice. The AI works fast; the Harness keeps the output correct and architecture-conform.
AI-built, deterministic tools — where we need data to decide (dependency graphs, migration plans, risk analyses), we don’t ask the AI for the answer. With AI assistance, we build a small, deterministic tool that produces the data.

Both mechanisms express one principle: use AI for speed, but validate the thing you rely on. What sets us apart from other AI suites is the engineering foundation and the requirements discipline that make the AI output trustworthy.

The XITASO Software Modernisation Suite

The suite is a set of AI-powered components that our software engineers operate as part of an engagement. Depending on the project and the assessment results, we select the components your system actually needs. How we apply them (the requirements-engineering method, the delivery model) is described in the sections that follow.

Click to zoom · drag to pan

How the core components work in depth

Choose a mechanism to see how it works:

mines every available source (e.g. existing documents, system screencasts, the code itself, database contents, log files, and usage statistics) to reconstruct requirements, business processes, and a domain glossary. This component supplies the raw material; the human-led method that turns it into validated requirements is described under “Requirements & process engineering” below and follows XITASO’s published RE practice [3]. Where a UI exists, it can also explore its interactions within a defined scope to map inputs to effects.

In depth · how it works

Requirements & process engineering: reconstructing what the system does for the business

The most common, and most expensive, mistake in modernisation is to treat a legacy system as only code to be re-written. A legacy system is three things at once: the code, the requirements and quality goals it silently fulfils, and the business processes and human workflows built on top of it. The last two are usually undocumented and live only in the heads of users and maintainers. Reading the source code shows how the software works; it does not tell you why it exists, which behaviour is essential versus accidental, or which workarounds users have invented to bridge its gaps.

So we do not rely on code analysis alone. We interview and observe the people who use the system, watch how they actually work, and reconstruct the requirements and processes from that. In one project the client would not release the source code at all for security reasons; the entire, successful analysis was carried out through document study, screencasts, interviews, and on-site observation. Code is one source among several, and often not the decisive one.

Reconstructing requirements and business processes is what decides whether modernisations succeed or fail. To address it, we documented an approach to analysing a decade-old, undocumented legacy system [3] and published it in a peer-reviewed paper. The suite operationalizes that approach and adds AI acceleration.

We run four complementary data-collection methods and feed them into three analysis artifacts:

Data collection: document analysis (triaging the mass of existing files down to the few that matter), video/screencast analysis (a recorded system demo is often the single richest source), semi-structured interviews with developers and users, and contextual inquiry (on-site observation of users doing their real work).
Data analysis: domain storytelling (visual, plain-language narratives of who does what with the system, readable by technical and non-technical stakeholders alike), user story / journey mapping, and BPMN process models of the business processes the system supports.

Two lessons from that work shape how we run every engagement:

Observation beats interviews for finding gaps. Watching users work reliably reveals workflow steps (and software shortcomings) that interviews alone miss, including the phone calls and side-spreadsheets people use to work around the system.
Some redundancy is a feature, not waste. Describing the same process as both a domain story and a BPMN diagram is not duplication for its own sake; the two views validate each other, and each speaks to a different stakeholder; that builds the shared understanding a modernisation decision needs.

What a deliverable actually looks like. A domain story, for example, is a single-page diagram in plain domain language: numbered arrows show that a test engineer pulls a machine’s build order from the system, records measured tolerances, and hands off to quality assurance for sign-off, readable by a shop-floor expert and an architect alike. The matching BPMN diagram expresses the same process in a notation your IT organization can hand to a workflow engine. In addition you receive a domain glossary, a requirements overview, and, where source code is available, a component dependency graph produced by an AI-built, deterministic tool.

How AI accelerates this work. AI changes the economics of requirements and process reconstruction, but not its nature. It triages hundreds of documents down to the few that matter, transcribes and analyses hours of screencasts, drafts the first version of a domain story or BPMN process model in minutes, and cross-checks reconstructed requirements against code and database for contradictions. What it does not do is decide what the business actually needs; that judgement stays with people. The effect: the costly, weeks-long analysis phase compresses to days, while the SME validation that keeps it honest is preserved.

Expert knowledge is not optional here. Your subject-matter experts act as the semantic anchor that validates every reconstructed requirement and lets us interpret old domain terms correctly; the same role that keeps AI output honest throughout the rest of the suite.

reconstructs how a system is really built, especially for multi-repository software in unfamiliar or discontinued technologies. Surfaces the actual architecture, the components and their interfaces, and the gap between intended and real design.

automated detection of technical flaws (mixed patterns, best-practice violations, outdated and end-of-life technology) and security weaknesses, with LLM-assisted triage that ranks and explains findings.

for a question no off-the-shelf tool answers, the suite builds a small, deterministic analysis tool for exactly that question in hours rather than a week. Real example: “which GUI components can be migrated next because all their child components are already migrated?” The suite generated a tool that parses the JavaScript AST, builds a dependency graph, and outputs a migration plan and a visual graph. The tool’s output is exact and reproducible, which makes it a trustworthy basis for migration decisions.

the execution engine: intelligent code generation (including automated language- and framework-version upgrades), cross-language and cross-framework migration, and code generation from the reconstructed requirements (spec-driven development).

In depth · how it works

Spec-Driven Generation & Transformation: the execution engine

Where requirements engineering reconstructs what the system must do, this component is the how of making the change. Spec-Driven Generation & Transformation is the suite’s execution engine: intelligent code generation (including automated language- and framework-version upgrades), cross-language and cross-framework migration, and code generation directly from the reconstructed requirements. It always runs inside the Harness (architecture and quality gates constrain every change) and against the legacy-as-oracle validation described below, so speed never comes at the cost of behaviour.

But the hard parts of execution are rarely the migration itself; they are the surrounding risks. We address them explicitly rather than hoping they don’t surface:

Data & schema migration. Schema evolution, data-quality issues, and the coexistence of old and new data models are handled with anti-corruption layers and, where needed, dual-write/backfill strategies, validated by the same differential tests we apply to code.
Non-functional requirements. Latency, throughput, availability, security, privacy, and maintainability are captured as quality-attribute scenarios in the Assessment and enforced as fitness functions, so a slice is not “done” until it meets them, not merely when it passes functional tests.
Production cutover & rollback. Because slices coexist behind the strangler boundary, we cut over with feature flags / parallel run and can roll back a slice without a system-wide reversal.
Observability. Each modernised slice ships with logging, metrics, and health checks, so regressions are caught in production, not by users.
Dependency and end-of-life risk. Unsupported frameworks, licensing constraints, and vendor EOL are captured in the discovery phase and factored into the Renovate/Renew/Replace decision.

proves that generated and migrated code preserves the system’s behaviour, by capturing the running legacy system as characterisation tests and running differential tests against it, inside architecture- and quality-gate CI. This component keeps the speed from introducing regressions (see “Legacy-as-oracle: proving the new code behaves like the old” below for the mechanism).

In depth · how it works

Legacy-as-oracle: proving the new code behaves like the old

This is the mechanism that lets us move fast without breaking behaviour:

Before we change anything, we capture the legacy system’s real behaviour as characterisation tests (golden-master tests), often generated at a high level (REST or UI).
During transformation we run differential tests: identical inputs go to both the legacy system and the new component, and any divergence in output fails the build.
The legacy system is therefore both what we replace and the reference implementation that proves the replacement is faithful.

A note on avoiding mistakes: golden-master tests capture current behaviour, including defects. We guard against silently enshrining bugs by pairing the generated tests with an SME review of the reconstructed requirements: where behaviour is wrong, it is corrected at the requirement level, not frozen as an oracle.

Technology stacks we have actually done this on: .NET Framework / C#, AngularJS and modern Angular, TypeScript, desktop (WinForms/WinUI) → cloud/web migrations, and industrial PLC code with WinCC HMIs.

the AI-for-Software-Engineering foundation the other six components run on, giving clients control over token cost and data privacy: self-hosted or client-tenant model deployments, source code and prompts kept out of vendor training data, and predictable per-token cost.

What sets the suite apart: an engineering harness, reconstructed requirements, and sovereign AI

In short, the suite differs on three points:

Point 1

Requirements and business processes are reconstructed

not only the code re-written; this is grounded in our published RE practice [3].

Point 2

AI runs inside an engineering harness

rather than just generating code, which avoids “technical debt 2.0.”

Point 3

The AI is sovereign and can be run on-premises

so your source code and prompts stay inside your trust boundary.

Frequently asked

A question we are asked frequently: why not just use GitHub Copilot or similar with our own team?

An internal team with off-the-shelf AI can accelerate typing, but without architecture guardrails, a behaviour-preserving harness, deterministic-tooling discipline, and requirements/process reconstruction, it tends to ship debt faster on top of a system nobody fully understands. A traditional modernisation consultancy brings people-heavy analysis at people-heavy cost, and rarely operates the AI stack that compresses that work by 5–15×. And doing nothing carries its own cost: every feature gets more expensive, and the eventual forced rewrite is the most expensive path of all.

What we bring is the engineering and requirements foundation around the AI. Our differentiation rests on three pillars:

1 · Architecture & Requirements

2 · Sovereign AI

3 · Code Quality Harness

Architecture & Requirements Excellence. The Assessment yields a target architecture with extensibility built in and a reconstructed picture of what the system must do for the business, expressed as concrete artifacts: a target-architecture diagram, a per-component decision matrix, quality-attribute (non-functional) scenarios, documented business processes, and domain stories. It is not a 1:1 copy of legacy patterns shipped faster.

Sovereign AI. On-premises / client-tenant deployment: your source code stays out of hyperscalers’ reach if you wish, and token cost is a planned line item, so security, privacy, and finance can all sign off. In practice this means a bespoke trust boundary with matching hosting, audit logging of AI interactions, and configurable data retention, deployable to meet regulated and IP-sensitive requirements.

Code Quality Harness. AI generates within best-practice guardrails, so speed does not become technical debt 2.0.

Backed by 14+ years of software engineering, real client delivery (not lab demos), published requirements-engineering practice, and an expert-led model that preserves your retiring experts’ knowledge in a base your people and your AI can inherit.

Our approach from assessment to innovation

We do not start with tools. We start with your goals. Our approach follows four clear steps (Discovery & Assessment → Strategy → Iterative Execution → Innovation) that map directly onto the commercial engagement steps below: the first two steps are what the Assessment delivers, the rest map one-to-one. The diagram visualizes how they line up; the steps are described in detail beneath it. Click through the steps:

Click to zoom · drag to pan

1 · Discovery & Assessment

2 · Strategy

3 · Iterative Execution

4 · Innovation

Phase 1 — Discovery & Assessment · “What must change, and why?”

Capture goals, constraints, stakeholders, and business processes; reconstruct requirements and domain terms with our published requirements-engineering method (interviews, contextual inquiry, domain storytelling, user story mapping, and BPMN process modelling) and reverse-engineer documentation and architecture from code and other sources. AI acts as a sparring partner; your experts remain the semantic anchor who contextualizes AI results; that is how we preserve the retiring generation’s knowledge instead of losing it.

maps to engagement step 1: Modernisation Assessment

Phase 2 — Strategy · Deciding what changes, and in what order.

Starting from the reconstructed requirements and the quality goals that should drive the design (extracted from architecture decision records where they exist, otherwise reconstructed with your experts), we define an extensible target architecture: the technology choices, module boundaries, and interfaces that make the modernised system a solid basis for new features rather than a faster copy of the old constraints. This is where the key decisions are made:

Per component: Renovate, Renew, or Replace. Each component gets an explicit decision plus a roadmap of achievable milestones that create value early.
Migration pattern, chosen honestly. Strangler Fig / vertical slices is our default, preferred when multiple data sources or interacting systems are involved. An AI-assisted big-bang release can be right for lower-complexity systems that are hard to split.
“Newer is not always better.” We resist blind 1:1 re-implementation and improve the user journey instead. Modernisation is not always about innovation: simpler maintenance, robustness, performance, and security are legitimate goals in their own right.

maps to engagement step 1: Modernisation Assessment

Phase 3 — Iterative Execution · Delivering in validated increments.

Step-by-step implementation, each shipped as a validated, running increment, with spec-driven development, AI-generated regression tests, and continuous validation against the legacy oracle and your experts. Each slice is validated before the next begins, so risk stays contained and you can pause at any milestone.

maps to engagement step 2: Modernise iteratively

Phase 4 — Innovation · Building on the modernised base.

Discovery, design, and implementation of new features on the now-stable, extensible architecture: the front-ends, analytics, APIs, and business models the legacy system blocked. Pausing at a modernised base is equally a legitimate outcome. Because that base is documented and extensible, you can resume the innovation later without repeating the groundwork. The concrete options are described under “Step 3 — Innovation on the modernised base” above.

maps to engagement step 3: Innovate on the base

Evidence: measured results from real client projects

Real projects, with the measurement basis disclosed so you can judge them for yourself:

XITASO documented a decade-old legacy system used by several hundred employees to design and test machines, a system with sparse documentation and no oversight from an IT department. The client declined to share the source code for security reasons, so the team reconstructed architecture, requirements, and business processes solely from ~100 provided documents (only ~25 of them useful), a 90-minute developer screencast, interviews, and an on-site contextual inquiry, analysed with domain storytelling, user story mapping, and BPMN process modelling. A recurring finding: gaps in the team’s understanding reliably marked real gaps in the software’s functionality. [3]

Result: the project delivered the architecture, requirements, and process documentation that gave the client a solid basis to decide on the system’s future; the same “modernise or not” decision the Assessment delivers.

In a historically grown client codebase, we migrated data models and a custom binary serialization from C# to TypeScript. About 20 prompts produced 2,363 lines of translated code and 79 automated tests in ~5 hours of agent time, versus a manual estimate of ~10 engineer-days; a ~15× speed-up on this task.

How measured: the agent’s wall-clock time vs. the team’s internal manual estimate for the same scope. The agent reached a validated, running state after each of the ~10 task blocks.
Scope & caveats: this is a well-bounded, mechanical translation task with strong test coverage, the kind of work AI is strongest at. It is not a statement about the speed of an entire system migration. Software engineers’ review and integration time are included but were minimal on this task, because any divergence failed the test build immediately.

For an undocumented PLC production line, our agentic reverse-engineering approach reconstructed the code’s structure and semantics as a basis for migration, a ~5× reduction in the manual effort of taking inventory.

How measured: reconstruction effort vs. the manual “inventory” estimate for the same system.
Scope & caveats: this measures the analysis/inventory phase, not the full migration. The output is a starting point that experts validate, not a finished migration.

We use an LLM to triage static security analysis (SAST) findings, which reduces false positives while flagging real vulnerabilities for human review. The LLM ranks and explains; it does not decide. Security teams keep sign-off, and findings are spot-checked to avoid missed positives. [4]

Doubled developer productivity across the practice. Across our entire AI-assisted engineering practice, the full method (not a single task) shows an effect of roughly 2× developer productivity, based on internal project data.

[3] Friedline, Jessica, and Jan-Philipp Steghöfer. “Combining Requirements Engineering Techniques for the Analysis of a Legacy System.” REFSQ Workshops. 2024.

[4] Wagner, J., Müller, S., Näther, C., Steghöfer, J. P., & Both, A. (2025, July). Towards effective complementary security analysis using large language models. In 2025 IEEE International Conference on Intelligence and Security Informatics (ISI) (pp. 21-28). IEEE.

▶ Next step

Book a free 45-minute scoping call.

Bring one system that worries you. We’ll tell you honestly whether you should modernise it, how AI would change the timeline, and what a fixed-price Assessment would cost.

Book a free scoping call

Software EvolutionModernisation + Innovation:AI-accelerated, expert-led.

At a glance:

Our offer: from a fixed-scope assessment to innovation

Modernisation Assessment

Modernise iteratively to reduce risk

Innovation on the modernised base