AI-Driven Modernization
We don’t use AI to convert your code. We use AI to build the converter.
AI is not the tool that converts — it is the tool that builds the conversion tool.
Consistent quality
Conversion is done by a tool that runs the same logic every time. Results don’t drift from one run to the next.
Your source stays out of AI
In the base approach, AI only works on the conversion tool’s code. There is no need to upload your source code to an AI.
Automated fixing and testing
Issues are tracked in Git and fixed in either the conversion tool or our library. Full automation with RPA is optional.
What happens when generative AI converts source directly
Give an AI the same source twice and it will not necessarily return the same result.
Uneven quality
AI does not always apply the same logic. Results change per screen and per run, so stabilizing overall quality takes time.
Source must leave your premises
Every conversion means uploading source code — including business logic — to an AI. Internal rules or contracts often don’t allow it.
From “AI converts” to “AI builds the tool”
The conversion tool converts the source; AI develops and improves that tool. Because the tool is a program, the same source always produces the same code.
Base approach: your source code is never uploaded to an AI
AI only sees two things: the conversion tool’s source code, and the issues registered in Git.
Conversion environment (your assets)
- Your source code
- Conversion tool
- Converted code (C# / .NET)
- Testing and verification
🔒 Source code never leaves this environment
AI development environment
- Conversion tool source code
- Issues registered in Git
The only two things AI sees
Two approaches compared
Building the tool wins on quality, security and accountability.
| Aspect | AI converts directly | AI builds the tool (ours) |
|---|---|---|
| Consistency | Results can change per run | Same input, same output — always |
| Quality | Each screen needs checking and rework | Fix the tool once; every screen benefits |
| Source code | Must be uploaded to AI | Not given to AI (except automation option) |
| Re-conversion | Results may differ from last time | Re-convert any number of times, identically |
| Accountability | Hard to explain why code looks as it does | Conversion rules are explainable as code |
Register, isolate, fix in one place
Register the issue, isolate the cause, and fix either the conversion tool or our library. If differences remain, they go back into Git.
Register the issue in Git
Symptom, steps to reproduce, expected result, target (screen / block / trigger) and screenshots. The quality of the record sets the pace of everything after it.
Isolate the cause
If the generated C# is wrong, it’s a conversion-tool issue. If the code is right but the compatible behaviour differs, it’s a library issue.
Fix the tool with AI → re-convert everything
The same pattern of problem disappears from every screen at once.
Update our library → verify by testing
Fixed with AI or by hand. Once the library is updated, every screen that uses it benefits.
Order entry: total is not updated when a line is added
- Symptom
- After adding detail lines, the total stays at 0
- Steps
- New order → enter 2 lines → Tab
- Expected
- Total equals the sum of lines (same as current Forms)
- Target
- Order entry (ORD010) / detail block / trigger
- Attached
- Screenshots of current and new system, logs
Let RPA run the cycle automatically
Conversion, build, screen operation, comparison with the current system, issue registration and fixing — run automatically with RPA and AI.
Repeat as often as needed
Every time the tool or library is fixed, all screens are re-tested automatically.
Checked against the current system
The same operations run on the current and new systems, and the results are compared.
People focus on judgement
Your team reviews differences, decides on the cause and gives final approval.
The automation option requires AI to reference source code. We only do this with your consent. About test automation →
What you gain
Conversion that doesn’t drift
The tool converts all source with the same logic. A fix is reflected on every screen, so quality is uniform.
Source stays inside
In the base approach your source is never uploaded to AI, so you can benefit from AI even under strict policies.
Fix and verify on repeat
RPA runs the register–fix–reconvert–test cycle, raising quality in a short time.
Services using this approach
Oracle Forms Migration →
FMB, triggers, PLL and RDF to Windows Forms and C#.
PowerBuilder Migration →
PowerScript and DataWindow to Windows Forms / Blazor.
Test Automation (RPA) →
Replay scenarios from the current system and compare screens.
Post-Migration Operations →
Keep maintaining with AI-assisted fixing after migration.
Next steps
Start small and check the conversion quality for yourself.
Asset inventory
We analyze screens, trigger lines and reports to size the migration.
PoC (trial conversion)
We convert a few of your screens so you can see the quality.
Plan and estimate
Based on the inventory and PoC, we present a plan and estimate.
Start with whether migration is feasible
Tell us the platform version and the number of screens, and we will send an initial answer. We are happy to sign an NDA first.
TEL +81-3-5962-3776