Red Hat AI’s GraphRAG field build turns codebases into migration plans

Red Hat AI Americas has published a deployable reference workflow for the “code understanding” phase of an agent-driven software factory. Rather than asking a coding model to rewrite a legacy application cold, the project first converts source repositories into metadata, builds a GraphRAG index and queries that graph for migration order, risky modules and architectural dependencies.

The repository is a field build, not a supported Red Hat product. Its value is as an inspectable pattern for teams deciding how much platform engineering sits underneath a credible code-modernization agent.

The deployment path

The project README targets OpenShift 4.18 or later and OpenShift AI 2.22 or later. It also assumes OpenShift AI Pipelines, MLflow, the model registry and catalog, object storage, at least 8 vCPUs and 24 GiB of RAM, plus separate GPU capacity for chat, embedding and coding models. The documented test setup lists an H200, H100 and L40S, making this a substantial platform deployment rather than a laptop quickstart.

Operators populate an environment file with Git, object-storage and model-endpoint credentials, then install the Helm resources through make install. The workflow can analyze a single repository selected through environment variables or a list of repositories supplied in JSON. A single-repository run can override the target URL and branch without rewriting the environment file.

What the pipeline produces

The workflow has three stages. Data generation turns relevant source files into text and metadata. It can also merge JSON produced by vulnerability scanners, dependency analyzers or static parsers from a repository-local .code_metadata directory, provided those files match the project’s schema.

Data indexing feeds that enriched fileset into Microsoft GraphRAG to build a graph representation of the codebase. Data analysis then runs canned or ad hoc questions against the index. The supplied examples ask for a migration order that reduces breaking changes, the modules riskiest to refactor first and the data stores present in a codebase. The resulting reports are intended to populate a refactoring catalog that can guide a later code-migration workflow.

This separation is the strongest part of the design: repository parsing, graph construction and migration reasoning are visible pipeline stages rather than one opaque agent prompt.

Treat the manifests as a starting point

The security boundary deserves equal attention. The sample environment template collects a Git personal access token, object-storage credentials and several model tokens. The pipeline Job injects that shared secret, configures Git credentials, fetches the selected repository and installs Python packages at runtime.

The supplied RBAC manifest binds the upload service account to the namespace-level admin ClusterRole and adds access to the Data Science Pipelines API. Persistent volumes for generated data and GraphRAG indexes are marked to survive Helm removal.

Before using this pattern with proprietary code, platform teams should narrow the service account, split and rotate credentials, pin and scan runtime dependencies, define retention for indexes and MLflow artifacts, and decide which source and scanner metadata may leave the cluster for model endpoints. The project demonstrates a useful analysis pipeline; its own manifests also show exactly where production hardening must begin.