AI can help rebuild a legacy application. It cannot, on its own, prove that the replacement behaves correctly. In our ongoing COBOL-to-.NET work at AMT, clear documentation and architecture specifications helped us generate a new codebase. Legacy integrations and functional issues still required engineers to investigate and correct them manually.
That distinction matters if you are deciding whether to modernise a system your business depends on. The opportunity is real, but the deliverable is not converted source code. It is a working system that preserves the business behaviour you need, integrates with its surroundings, and can be operated safely.
I have spent over two decades working on enterprise software. What interests me about AI-assisted legacy application modernization is not the promise of removing engineers from the process. It is the possibility of using their judgement where it matters most: understanding the old system, designing the new one, and checking the gap between them.
What our COBOL-to-.NET rebuild actually involved
We are working on the rebuild of a legacy hotel reservation application in .NET, with a multi-tenant architecture as the target. I am keeping the client anonymous, and this is an account of work in progress, not a completed migration case study.
We supplied the COBOL source to AI, studied the code, and provided supporting documentation and architecture specifications. With that context, AI helped generate the replacement codebase. But the output had a lot of issues. Our team has been working through them one by one and checking that the rebuilt application works with the integrations surrounding it.
The important lesson is not that AI failed or that AI solved everything. It helped with the rebuild, but generating code and making the application work were separate pieces of work. We have not established a final delivery time, a cost reduction, or a production outcome to report here.
Code conversion is not application modernization
Translating COBOL into C# changes the implementation language. Modernising an application also means deciding how data is accessed, how integrations behave, how users are separated, and how the system is deployed and supported. Those decisions do not follow automatically from the source code.
A legacy system can contain important behaviour that is spread across application code, database structures, operational routines and connected systems. If you only convert the code you can see, you can miss the context that made it work.
In a reservation application, questions worth testing include how availability changes after a booking, how amendments and cancellations are handled, and what happens when an external system is unavailable. These are examples of validation questions, not claims about particular defects in our client's system. The point is to define the expected behaviour before accepting the generated implementation.
A new application that compiles is a starting point. It is not evidence that every important workflow has survived the move.
When legacy systems have no APIs
Some of the systems around a legacy application do not expose modern APIs. They may offer direct access to data rather than a service interface that a new application can safely consume. That was one of the integration challenges we discussed in this rebuild.
Our approach has included adding API wrappers around legacy data access so the new application can obtain the data through an interface. This is engineering work around the conversion, not a capability that appears simply because the new code is written in .NET.
A wrapper creates a boundary where engineers can define the data contract and decide how access, validation and errors should work. It does not make an unreliable data source reliable by itself, and it does not remove the need to test the systems on both sides.
I explored a related approach in Bridging Legacy APIs with Modern AI. That article is about connecting existing systems to AI; this rebuild is about replacing an application. Both depend on understanding and designing the integration boundary rather than treating it as an afterthought.
Moving to multi-tenant .NET changes the problem
In the older reservation architecture we discussed, databases were associated with individual hotel installations. Moving toward a shared, multi-tenant architecture is therefore more than changing the programming language or moving a server into the cloud.
The target design needs explicit answers about which property owns each record, which users may access it, and how integrations preserve that separation. A query that was acceptable inside one isolated installation needs to be examined again when the application serves multiple properties.
These are design and validation requirements for the target architecture, not a claim that every one has already been delivered in our ongoing project. AI can help implement an architecture that engineers specify. It should not be left to invent the tenant boundaries or decide which business rules can be discarded.
Why domain knowledge matters more than a clever prompt
In the conversation behind this article, I kept returning to one point: you need in-depth domain knowledge to work effectively with AI. Clear instructions matter, but someone has to know what those instructions should contain.
When generated code behaves differently from the old system, an engineer needs to determine whether the cause is misunderstood business logic, a changed data assumption, an integration mismatch, or a deliberate change in requirements. Asking AI to keep fixing the symptom without that diagnosis can create more uncertainty.
The strongest review combines source-code understanding with knowledge from the people who operate the application. An unusual rule may be an obsolete workaround, or it may be essential to a customer's daily work. Its age alone does not tell you which.
That is the same principle behind Vibe Coding Done Right: AI-assisted development still needs engineering discipline. In legacy modernization, that discipline must also preserve the knowledge already embedded in the system.
A practical framework for an AI-assisted migration
Our ongoing rebuild illustrates the need for code study, documentation, architectural direction and manual integration work. For teams planning a similar migration, I would organise the work around the following checkpoints. This is a recommended framework, not a claim that every checkpoint below has already been completed on this project.
- ▹Understand what must survive. Map critical workflows, data stores, integrations and operational dependencies with the people who know the system.
- ▹Specify the target architecture. Decide service boundaries, data ownership and tenancy requirements before asking AI to generate the replacement.
- ▹Use AI for bounded implementation work. Supply the relevant source and reviewed documentation, then assess the output against the specification.
- ▹Repair the integration seams. Build wrappers or adapters where necessary, define their contracts, and test error handling as well as successful requests.
- ▹Verify business behaviour. Compare old and new outcomes using controlled inputs and investigate differences before accepting them.
- ▹Plan the release and recovery path. Decide how to migrate data, monitor the new system, and recover if a release does not behave as expected.
Before sharing source code or customer information with any AI tool, establish permission and check the tool's data-handling terms. Use appropriately controlled environments and test data. The recording does not establish the specific controls used on this project, so I am not making claims about them here.
For the delivery choices beyond code conversion, see how we modernise legacy systems in stages. A phased migration, a replacement, and an API-led extension solve different problems; the right choice depends on what needs to change and what must keep running.
Questions to ask a legacy modernization partner
A useful proposal should explain more than which model will generate the code. Ask the team what evidence will show that the replacement is ready to take responsibility for your business workflows.
- ▹Who will explain the legacy behaviour? Identify the engineers and business users who can resolve undocumented rules.
- ▹How will you check functional parity? Look for defined test cases, comparison criteria and a process for handling intentional differences.
- ▹What happens to integrations without APIs? Ask which wrappers are needed and who will own and maintain them.
- ▹How will shared data stay separated? If multi-tenancy is the goal, require explicit access boundaries and tests.
- ▹What is the release and rollback plan? Ask how data consistency and recovery will be handled, not just how the new application will be deployed.
- ▹What does the estimate include? Separate conversion work from integration repair, testing, data migration and operational readiness.
If you already have an AI-generated replacement that does not work reliably, more generation may not be the next step. A focused review of the architecture, failing workflows and integration contracts can help identify what actually needs to change.
Common questions about AI and COBOL modernization
Can AI convert COBOL to .NET? It can assist with producing a .NET implementation from COBOL source and supporting specifications. In our ongoing rebuild, the generated application still had issues requiring manual correction. Conversion is not a guarantee of functional parity or production readiness.
Does every COBOL application need a full rewrite? No. Assess the application's business value, maintainability, integration needs and operational risks first. Retaining part of the system, adding an API layer, or replacing functionality in stages may be more appropriate than rebuilding everything.
How much does AI-assisted legacy modernization cost? This recording does not provide a defensible price or saving. Scope depends on documentation quality, dependencies, target architecture, data migration and the evidence required for release. An estimate should include the work after code generation, not assume it disappears.
Can this be done without downtime? AI code generation does not establish that. Availability depends on the migration design, data synchronisation, release strategy and recovery plan. Our ongoing reservation rebuild is not evidence of a completed zero-downtime cutover.
Where AMT can help
AMT has been building enterprise software since 2004. This ongoing COBOL-to-.NET engagement reflects the work I believe an engineering partner should be willing to discuss openly: the generated code, the issues that remain, and the human effort needed to resolve them.
If you are planning a legacy application modernization or trying to make an AI-assisted rebuild work, talk to our engineering team about your migration. Tell us what the system does, what it connects to, what you want to change, and what cannot stop working. Do not send confidential source code through the contact form; we can agree a suitable review process first.
If you are still evaluating your options, start with our phased modernization approach and how we deliver engineering work. The aim is not to replace old code with new code as quickly as possible. It is to preserve what your business depends on while building a system you can maintain and evolve.