Red Hat pitches its migration factory against a Stanford figure of 0-10 percent on legacy code

A developer running Red Hat Developer Lightspeed for MTA can apply a suggested fix to a single occurrence of a migration issue or to every occurrence in the application, from the IDE ^[11]. Then they read the diff. Of the three stalls Red Hat lists, the pipeline is aimed at the first: MTA has already scanned the code and pinned each issue to its exact location, and Lightspeed builds its fix from that analysis plus the Kantra ruleset instead of inferring the dependency graph on its own ^[9][10]. Auditing the generated code, and proving it meets security, performance and compliance standards, still lands on whoever reviews the change ^[4][5]. Red Hat's stated outcomes for the combination are accuracy and single-click application ^[19].

Take the cited bands at their midpoints. Greenfield is 35 percent and the highly complex enterprise codebase is 5 percent, so the claimed effect on the hardest work is one seventh of the effect on the easiest ^[16]. Read as effort saved, a job estimated at 100 developer-weeks unassisted lands at 65 weeks on the greenfield number and 95 weeks on the complex one ^[17]. Thirty weeks of plan sit between those two figures, and the 0-10 percent band is the one that covers maintaining legacy infrastructure ^[2].

What teams tell themselves about a migration factory is that the agent does the migration. What this pipeline asks for is rules. Kantra rules are open source and support polyglot languages, and Red Hat says an existing code assistant agent such as Claude or Cursor can create them ^[10][14]. The example in the post matches one pattern: a Go reference to v1beta1.CustomResourceDefinition, labelled for a Kubernetes target, with an effort field set to 1 ^[13]. Someone still has to know that pattern matters in your estate, write the rule, and keep improving the context in the integrated solutions server that Red Hat says lets a team of developers steer a large-scale migration ^[18].

So sort the backlog on two axes before deciding what the pipeline is for. First axis: whether the change can be stated as a pattern match, the way that CustomResourceDefinition rule is ^[13]. Second axis: how expensive verification is, meaning who reads the diff and against what standard ^[5]. Rule-shaped changes with cheap verification are where a grounded pipeline should beat a general-purpose assistant, because the model is handed the location rather than hunting for it ^[9]. Changes that resist a rule, or that a compliance reviewer has to sign, sit in the band the cited study puts at 0-10 percent, and they should be staffed and costed there ^[2].