What’s the best way to turn a profitable AlphaBASIC program into a web application?

There is no need to force the project into a literal BASIC-to-web conversion. A conventional backend in .NET, Java, or another familiar stack can preserve the business rules while making the system maintainable. AI tools may help generate repetitive models, forms, and tests, but they should not be trusted to infer tax rules without review.

The project should be treated as a requirements and verification exercise first, and a coding exercise second. Document every rule, identify who signs off on the results, and keep a clear test suite for each government submission scenario.

A rewrite is very feasible if the specifications are accurate. A detailed manual covering business workflow, screen flow, validations, lookup tables, and inputs and outputs can provide most of the requirements. The remaining gaps should be found by inspecting the source code and interviewing the original developer or experienced users.

I would build a small vertical slice first—one complete data-entry-to-submission workflow—then compare it against the legacy application before expanding. That will expose hidden rules early and give the owner something concrete to evaluate.

The database details may be the hardest part of a direct conversion. AlphaBASIC installations sometimes use platform-specific database products and extensions, so first identify exactly how records, indexes, lookups, reports, and file locking work. Do not assume the data can be moved cleanly just because the forms look simple.

The user interface is usually easier to replace than the underlying rules. Preserve the core behavior, but take the opportunity to remove unused features, improve workflows, and use newer government APIs if they are available.

Because this handles tax submissions, I would avoid replacing the calculation and validation engine all at once. If possible, build a web interface that sends data to the existing program and receives its results. That lets you modernize the user experience while keeping the proven business logic in place during the first phase.

If the old system cannot be integrated, then recreate the rules carefully and compare the new and old systems with large sets of real or anonymized cases. Regression testing, edge cases, audit trails, and a period of running both systems in parallel are more important than the choice of framework.

I would treat this as a new web application rather than trying to translate the old screens line by line. Use the existing source, manual, screenshots, and interviews with users to document the workflows, entities, validations, calculations, reports, and government submission process. The manual sounds especially valuable because it explains why each step exists, not just what each screen looks like.

A sensible target could be a REST API with a modern front end, such as React, Angular, or Blazor, with the domain model and database designed around the actual business processes. Generate documentation and automated tests as you go so future developers know what the system is supposed to do.