Rule-Based Engine vs. AI Engine: What 26 Years of Legacy Migrations Taught Us About the Real Cost of "Free" Conversion

Every week, another headline claims that AI engines just compressed months of engineering into a single day. The numbers are intoxicating: Stripe reportedly migrated 50 million lines in a day, saving $200,000 and over two months of manual work. For years, many executives treated automated migration with skepticism – even when the tools existed. Headlines like this change something deeper than vendor preference: they shift the belief that large-scale migration can be automated at all, and that AI can be the engine doing it. For any executive staring at a legacy codebase, the natural next thought is to skip the traditional migration vendor entirely and hand the problem to the latest frontier model.

At Ispirer, we have spent 26 years building deterministic tools for database migration and legacy code conversion. We have seen the same cycle repeat itself: a breakthrough artificial intelligence engine launches, the market buzzes, and a wave of teams tries to "AI their way out" of technical debt. Some succeed on small, contained experiments. Many more quietly burn through quarters of engineering time before calling someone who has done this before.

This article is not an anti-AI manifesto. It is a side-by-side comparison of three real approaches to the same real problem – based on a live project we are currently delivering. The goal is simple: to show where each approach wins, where it breaks, and why the economics of legacy modernization are rarely as straightforward as the benchmarks suggest.

The Case Study: 1.8 Million Lines of Delphi

A Latam ERP software provider approached us with a business-critical application written in Delphi over the course of two decades. The system contains approximately 1.8 million lines of code, spans multiple modules, and carries 20 years of embedded business logic. The target stack was C# and WPF – a shift not just in syntax, but in architecture, UI paradigm, and runtime behavior.

This is the kind of project where a Ruby-to-Ruby migration headline is not directly applicable. You are not bumping a framework version. You are translating across languages and paradigms, which means every API call, memory model assumption, and UI event loop must be re-expressed.

We evaluated and priced three approaches:

Approach 1: Rule-Based Engine (CodeWays) – Full-Service Delivery

The Ispirer rule-based engine, CodeWays, is the product of 20+ years of pattern accumulation. It is deterministic: if you feed the same 1.8 million lines through the converter today, tomorrow, or next year, you get the same output, because the transformations are predefined by experts, tested on real projects, and cover the most common legacy patterns – not probabilistic inference.

For this project, the engine automated roughly 70–80% of the conversion out of the box. The remaining 20-30% – edge cases, business-logic optimizations, framework-specific UI work, and architectural alignment – required manual refinement by our engineering team.

The numbers:

• Conversion phase: 13 months
• Acceptance and stabilization: 5 months
• Team: 4 dedicated engineers
• Fixed-price delivery: $450,000

The trade-off is clear: you pay for stability and accountability. You get a vendor who signs a contract, fixes the bugs during acceptance, and guarantees that the final application compiles, runs, and preserves the original business logic. The downside is that pure automation cannot fully eliminate the human phase, and that human phase is priced into the engagement.

Approach 2: AI-Only (Fable 5) – Client-Side Execution

Let us assume the client’s internal team decides to use Claude Fable 5 directly. Anthropic’s public case studies show it migrating 50 million lines of Ruby in a single day, compressing months of work. For a team that knows how to prompt, review, and iterate, Fable 5 can be a powerful accelerator.

However, the Stripe case is a migration within the Ruby ecosystem. Delphi to C# is not a version bump. It is a language switch, a UI framework swap, and a runtime change.

If a skilled client team takes an intelligent, modular approach – breaking the 1.8M-line monolith into modules, designing prompts per subsystem, and running iterative reviews – the project looks roughly like this:

The numbers:

• Architecture and harness setup: 2-3 months
• Modular conversion and review: 10-12 months
• Stabilization and "seam-fixing": 4-6 months
• Total timeline: 16-21 months
• API costs: ~$8,000 - $15,000 based on early published rates , but this estimate is subject to significant adjustment as the model matures, demand scales, and – more importantly – as access itself becomes uncertain. Just days after the Fable 5 launch, the U.S. government issued an export control directive requiring Anthropic to suspend access to Fable 5 and Mythos 5 for all foreign nationals, forcing the company to disable the models abruptly for all users. For any enterprise planning a multi-month migration, that kind of access volatility is an operational risk, not a footnote.
• Engineering team (4 fully-loaded engineers): ~$400,000 - $500,000
• Total estimated cost: $410,000 - $520,000+

The critical difference versus a vendor-led engagement is risk and consistency.

Fable 5 or other top notch models operate on probability distributions. Across a 1.8M-line codebase, it may resolve similar patterns in Module A and Module B with slightly different C# idioms. When the modules are reassembled, the "seams" – boundaries where coding styles, patterns, or architectural assumptions diverge – require manual reconciliation. This is not a bug in the model; it is a natural property of probabilistic inference over long contexts.

The pure AI approach also shifts 100% of the accountability to the client team. If the converted codebase is inconsistent, if the acceptance testing reveals drift between modules, or if the timeline slips by six months, there is no vendor contract to enforce. The team owns the outcome in front of the board, the CFO, and the end users.

Approach 3: Hybrid – CodeWays + AI-Assisted Refinement

We begin with the CodeWays rule-based engine to deliver the deterministic 70-80% conversion. This creates a stable, predictable foundation. Then, our migration engineers use AI engines to accelerate the refinement of specific modules, pattern matching, and repetitive adaptation tasks.

Because the rule-based engine already handles the bulk translation, the AI is used as a precision instrument, not a primary engine. The team does not need to prompt the model to re-convert the entire codebase on every iteration. They are working on a known, stable baseline.

The numbers:

• Conversion phase: 12 months
• Acceptance and stabilization: 4 months
• Team: 3 engineers + AI tooling
• Fixed-price delivery: $340,000

The result is a 16-month total timeline with a fixed budget, backed by a vendor contract. The client knows exactly what they will pay and what they will receive. The AI engine is not asked to carry the project; it is used to speed up the parts where it is most reliable.

The Factor Nobody Benchmarks: Determinism

AI benchmarks measure accuracy, speed, and token efficiency. They rarely measure determinism – the guarantee that running the same process twice yields the same result.

For a legacy migration, determinism is not a philosophical preference. It is a project management necessity. When a client funds a 15-month modernization, they need to plan parallel workstreams: training, infrastructure rollout, user communication. If the converted codebase drifts between iterations, the downstream plan drifts with it.

The rule-based engine guarantees that the bulk conversion does not drift. The hybrid model preserves that guarantee while adding AI velocity to the tail end of the work. The AI-only model trades that guarantee for flexibility – which is valuable, but expensive to manage at scale.

The Accountability Question

There is one question every team should ask before choosing an AI-first strategy:

If the migration slips by two quarters and the budget doubles, who presents that to the board?

With a fixed-price vendor engagement, the answer is clear. With an internal AI experiment, the answer is the engineering lead who championed the approach.

That is not an argument against AI. It is an argument for understanding who carries the risk. The headlines celebrating AI migrations rarely mention the review cycles, the seam-fixing, the context-window limitations on cross-language refactoring, or the acceptance testing that follows. Those costs are real, even if they are not in the press release.

Conclusion: The Right Engine for the Right Job

AI is not replacing legacy modernization. It is becoming a new tool within it. The teams that benefit most are the ones that use AI where it is strongest – acceleration, pattern suggestion, and rapid iteration – while relying on deterministic engines for the foundation.

After 26 years in this space, our view is straightforward:

• Rule-based engines give you stability and a fixed contract.
• AI-only gives you speed and flexibility, but demands that you own the risk and the timeline.
• Hybrid gives you the closest thing to both: a predictable foundation, a faster finish, and a vendor who stands behind the result.

If you are evaluating a database migration, legacy code modernization, or any large-scale transformation project, the decision is not "AI or not AI." It is where to place AI in the workflow so that it amplifies your team rather than replacing your plan with probability.

If you are facing a database migration, or code modernization challenge, I would welcome a conversation. Whether you are comparing legacy migration service costs, benchmarking vendors, or simply trying to understand the real effort behind a headline, feel free to reach out directly.

And if you have already tried the AI-only path and found that the real cost is not the API bill – it is the months of fixing inconsistent outputs, re-stitching modules, and acceptance cycles that keep stretching – I would especially like to hear from you. Sometimes the most useful conversation happens after the first AI experiment, when the real effort becomes clear.