I’d be careful about trying to use AI as a “convert my Clarion app to Java/Angular” button. That’s not where it shines, and you’ll probably burn time cleaning up half-correct output.
Where AI does help a lot in this scenario is two things: understanding legacy behavior and accelerating repetitive scaffolding.
If I were in your shoes, I’d approach it like this:
First, use AI to extract behavior from the Clarion side. Export procedures (TXA if possible) and feed them in chunks. Don’t ask it to convert the code. Ask it to:
- Summarize what the procedure does
- List tables read/written
- Extract validation rules
- Identify calculations and defaulting logic
- Note side effects
You’re basically using AI to generate the documentation your Clarion 6 app never had. That becomes your migration spec.
Second, migrate in functional slices, not layers. One browse + form. One workflow. One process. Keep the SQL DB stable like you’re doing, but replace behavior one slice at a time.
For each slice:
- Produce a short behavior spec (AI-assisted, human reviewed)
- Define the API contract
- Implement cleanly in Java/Angular
- Compare behavior against the legacy app
AI works much better when the target is clearly defined.
Also, build one really clean “golden example” module in the new stack. After that, Copilot becomes far more useful because it can mirror your established patterns instead of inventing structure.
The biggest risk in Clarion migrations isn’t SQL, it’s hidden business rules:
- Validation buried in ACCEPT loops
- Browse filters enforcing rules
- Default values in embeds
- Implicit locking assumptions
AI can help you find those, but you still need to confirm intent.
The bottom line is that AI won’t magically migrate the app for you. But if you use it as a documentation extractor and a scaffolding accelerator, it can meaningfully speed up the process.
That’s where I’ve seen it provide real leverage.
Good luck on your project!
Charles