Skip to content
Notifications
Clear all

What AI assistant works best for legacy code migration

2 Posts
2 Users
0 Reactions
0 Views
(@jessicap)
Trusted Member
Joined: 1 week ago
Posts: 42
Topic starter   [#9548]

I've been tasked with helping my team migrate a large, old PHP monolith (think PHP 5.6 era) to a more modern, supported version, and I've been experimenting with different AI assistants to see which one can handle the nuance. The goal is to refactor deprecated functions, update API calls, and navigate some very... creative... architectural patterns.

So far, my experience has been a mixed bag. For straightforward syntax updates, most assistants do okay. But they consistently fail in two key areas when the code gets gnarly:

1. **Understanding the *intent* of legacy patterns.** They'll often suggest a modern, "correct" replacement that completely breaks the original, often weird, logic flow. For example, suggesting a PDO prepared statement to replace a `mysql_*` function call, but missing that the surrounding code was deliberately swallowing errors in a specific way for a third-party integration.

2. **Partial refactors.** They'll happily change a function signature in one file but have no awareness of the 50 other files that call it, creating a cascade of silent errors. It gives you a false sense of security.

I tried a prompt like: "Convert this legacy PHP function to use PDO and modern error handling, but preserve the existing error logging to the `legacy_log` table and the default return value of 'ERROR'."

The assistant updated the database connection and used try/catch, but it replaced the custom logging with a generic `exception->getMessage()` log, which loses critical context our system needs. The "correct" answer was to wrap the new PDO logic inside the old logging structure.

Has anyone found an AI tool or a specific prompting strategy that excels at this kind of context-aware, *conservative* migration work? One that prioritizes understanding the existing behavior first, before applying a shiny new best practice? I'm less interested in greenfield code and more in accurate, incremental renovation.


good docs save lives


   
Quote
(@joshuaa)
Trusted Member
Joined: 6 days ago
Posts: 45
 

I'm a staff platform engineer at a mid-sized fintech (~200 engineers), and I've overseen the decomposition of a massive Java 7 monolith into microservices, plus a separate effort to modernize a PHP 5.3 internal CMS. In production, we use a mix of GPT-4 via API for automated tasks and Cursor for IDE-level work.

**Core Comparison: AI Assistants for Legacy Migration**

1. **Context Window & Codebase Awareness:** For legacy work, the single most important spec is the context size. Cursor (using Claude 3.5 Sonnet) offers a ~200k token context. GitHub Copilot Chat, using GPT-4, caps at about 8k in the IDE. That difference is everything for your "50 other files" problem. With Cursor, I can feed it 10+ files of relevant, gnarly legacy patterns and ask for a coordinated refactor. Copilot will only see the single file you have open and guess.

2. **Pricing & Access Model:** Cursor is a flat $20/user/month. GitHub Copilot is $10/user/month for individuals, but enterprise pricing can be $19-$39 depending on terms and security needs. The hidden cost is API usage: if you use the OpenAI API (GPT-4 Turbo) directly for batch processing, you pay per token. For a large codebase, running thousands of files through the API for analysis can cost hundreds of dollars, but it's a one-time project cost versus a subscription.

3. **Deployment & Integration Effort:** GitHub Copilot integrates directly into your IDE (VS Code, JetBrains) with near-zero config. Cursor is a fork of VS Code, so you have to switch editors, which can be a non-starter for some teams. Using the OpenAI/ChatGPT API requires you to build your own tooling - a simple script to feed files and prompts - which adds dev time but gives you total control over the workflow and output format.

4. **Handling Weird Legacy Intent:** This is where model choice matters. In my tests, Claude 3 (via Cursor or API) is better at inferring the original programmer's *intent* from messy code and preserving it, even if it's ugly. GPT-4 is more likely to "correct" the code to modern standards, breaking that weird error-swallowing behavior you mentioned. For the most bizarre patterns, I got the best results by using the Claude 3 Opus API (expensive, but high accuracy) to generate a plan, then using Cursor (Sonnet) to execute.

**My Pick**

For your specific task - migrating a large, interconnected PHP monolith with creative patterns - I'd recommend **Cursor**. The massive context window is the killer feature for tracking changes across dozens of files. If you can't switch editors, then the next best is using the **Claude 3 API** directly with custom scripts, but that's a heavier lift. To make the call clean, tell us: 1) Can your team switch from their current IDE? 2) Is this a one-time project or an ongoing modernization effort?


Design for failure.


   
ReplyQuote