G.Tx Feasibility Analysis. From unknown legacy system to a defensible modernization plan.

A traditional discovery relies on interviews, existing documentation, and what the team remembers. G.Tx Feasibility Analysis reconstructs the system directly from the source code using the G.Tx GenAI engine, then validates that picture with your team on-site. The output isn’t a slide of assumptions — it’s a fact-based modernization plan derived from what the codebase actually contains, with accurate cost and timeline estimates you can defend in a steering committee.

Most estimates fail because they’re built on assumptions about a codebase nobody has measured. G.Tx runs automated analysis against the actual source code, so the estimate is derived from real code volume — not from memory. This matters because a large share of a codebase can be dead code and translation overhead that won’t exist in the modernized system. Quantifying what’s real before budgeting is the core of the analysis.

A consolidated current-state picture, a target vision (architecture, tech stack, ERD, dependencies, functional and non-functional requirements), and a modernization plan (phased roadmap and backlog, effort sizing, budget estimate, cooperation model, risk assessment). It’s delivered as the Feasibility Analysis deck and the G.Tx Assessment report — structured to take to your steering committee.

Feasibility Analysis runs 2–4 weeks. We start from your product demo, source code, and any available documentation. The on-site portion involves your stakeholders and key users in a goals & anti-goals session, an event storming workshop, interviews, and effort estimation. Most of the heavy analysis is automated; your team’s time goes into aligning on goals and validating findings.

Significantly. In one auto-translated codebase, roughly 45–55% of the business-logic layer would not exist in a hand-written equivalent. Quoting the full line count anchors the budget to a codebase that’s partly fiction. Feasibility Analysis separates real logic from removable overhead, which is often where half the anticipated scope disappears.

The Assessment (around one week, free) answers whether your system is a candidate for AI-driven transformation and surfaces the top risks. Feasibility Analysis (2–4 weeks) is the next step: it produces the actual modernization plan, pilot scoping, business and technical documentation, and budget estimation. The Assessment qualifies the opportunity; Feasibility Analysis turns it into a costed, phased plan.

The G.Tx Understand workflows analyze the source directly to rebuild business and technical documentation — dependency maps, architectural reconstruction, data structures, and static/semantic findings — independent of whatever documentation does or doesn’t exist. This works specifically for situations where the only reliable source of truth is the code itself, including Java that was mechanically translated from COBOL.

The analysis is designed to answer exactly that, before any commitment. Once dead code and hidden dependencies are mapped, in-place hardening (removing overhead, recovering documentation, restoring testability) is sometimes the higher-ROI path; in other cases migration or a partial rewrite fits better. The decision follows the evidence rather than preceding it.

The deep code analysis, documentation reconstruction, and dependency mapping are run by the G.Tx GenAI engine. Our experts shape the scope, facilitate the on-site sessions, interpret the findings, and build the modernization plan and estimates on top of them. The combination is deliberate — automated evidence, human judgment on what to do with it.

No. Your code is never used to train or fine-tune any model. Before analysis begins, we agree the LLM deployment model with you — from fully on-premises and private cloud to a Grape Up managed environment or a client-approved public model — and your code is processed only within the agreed scope and isolated per engagement.