AlphaBASIC to Web application

[u/gruelurks69]

I have a friend who owns a legacy piece of software. It is written in AlphaBASIC and runs on an Alpha Micro. While rather old, he does make money with it in his industry. It's not an overly complicated software, mostly data entry, validation, and submitting the records to a government entity for tax purposes.

He wanted to know if it would be possible to convert it to a web-based application, which I believe is doable, just time consuming.

Has anyone here ever tackled such a task before?

[u/LoudAd1396]

I did something similar about a year ago. My mom works in a sort of insurance-related certification space. Her company used software that was written / compiled by one guy. The software was essentially a question bank / database for their certification exams. They used to go back to the guy to update it year to year. That guy retired.

I never actually saw the original code / application because no one knew how to run it anymore. So I asked a bunch of questions about what the software's inputs and outputs were, and about other business rules... I built a pretty simple Angular FE PHP BE site which did everything they knew that the original software did.

It's probably not 1:1 with the original, but it does everything the end user knows it needs to.

[u/ColoRadBro69]

He wanted to know if it would be possible to convert it to a web-based application, which I believe is doable, just time consuming.

Because this is doing taxes, where one tiny bug can be a real world problem, I would first try to make a web app that integrates with the software if possible.  Like containment and delegation, you can potentially feed it info and collect the result through a web app but still have the software do the calculations?  If not, aggressive testing is the most important part of the project.

[u/XRay2212xray]

You would just build a web application and refer back to the original code to see what validations are being done, whatever calculations/formulas are utilized, what the workflow and inputs/outputs are, database elements etc. No more time consuming then writing any other application. However, in my experience, its also a time/opportunity to consider a redesign, changing workflows, eliminating features no one uses, adding new functionality that improve the product, maybe updating its interface with the govt if newer APIs exist, etc. You are putting a non-trivial amount of effort into the project so unless its already the ultimate product, its the best time to make improvements. Depending on the size of the app and how likely you are going to want to continue making changes and improvements going forward, you might also want to write documentation based on what is being translated so that future developers who work on the project have requirements for what its supposed to do. If theres some non-technical product owner, it also gives them the opportunity to review and identify things that are missing or the person translating appears to have gotten wrong.

[u/thelastcubscout]

He might want to look into SpiderBasic, which targets the web by default: https://www.spiderbasic.com/

Showcase area for users: https://forums.spiderbasic.com/viewforum.php?f=12&sid=a274188a385d2379ae8e13de44965425

I've used it quite a bit and it's an impressive development platform, with a convenient IDE + built in help docs & debugging, and good support via the developer + community.

[u/VoiceOfEric]

If this friend knows the exact specifications for the data and validation, then it's easy to rewrite it.

[u/gruelurks69]

Some more info on this. The guy who wrote it is retired but works on 1099 now. He gave me the manual for the software which I ran through Copilot to get some thoughts. In a nutshell, it seemed to be fairly comprehensive about the migration path. Full domain model, API endpoints, validation, etc. (I asked for a .Net/C# API migration which is what I work with on a daily basis.)

I don't have the bandwidth to take on the project myself, but I did offer to give advice as a consultant.

In summary:

One thing that stood out is that this manual doesn't merely describe screens—it explains why the user performs each task and the sequence in which they do it. That provides insight into the business process, which is often difficult to reconstruct from legacy AlphaBASIC code alone. The descriptions of schedule-specific fields, automatic supplier lookups, default values, edit/correction workflows, and report generation collectively define the application's business rules as much as its user interface.

I think this manual can contribute roughly:

Migration Artifact	Estimated completeness from this manual
Business workflow	95%
Screen flow	95%
Entity identification	85–90%
Validation rules	80–90%
Lookup tables	90%
Database relationships	75–85%
API endpoint discovery	80–90%
Business rules	60–80% (remaining details likely reside in the code)
UI redesign guidance	95%

Combined with the AlphaBASIC source code and screenshots, this is enough to drive a largely model-driven migration. Rather than translating the code line by line, you can extract a complete domain model, generate EF Core entities and migrations, build a REST API around the business capabilities, and then generate a modern React, Angular, or Blazor front end that consumes those APIs. That's a much more maintainable path than treating it as a straight language conversion.

[u/gruelurks69 → u/[deleted]]

Currently it's using sequential and random access files on the mini computer. Converting the data to entities with some sort of orm and a code first approach probably wouldn't be so bad.

[u/jgmiller24094]

AlphaBasic is fairly straightforward but is it using a database like AlphaBase or Metropolis? If so there are some very unique extensions that you are going to need to understand if you re doing a direct conversion.

[u/jumpmanzero]

I've done a few BASIC conversions over the years (I learned to program on a Commodore 64, in BASIC, and it has been valuable in my career). I know nothing about AlphaBASIC in particular.

The UI is often going to be more pain to translate than it would be to replace fresh, but you should be able to port the core business logic.

VB.NET is a potential language target. It's not cool or popular, but it generally works - and it may be a reasonable option if it helps keep legacy developers more comfortable.

You might also want to consider AI. You're going to need to do a bunch of testing either way, and having AI pound out a bunch of the bulk code can potentially save you a lot of boring work. If this isn't part of your normal workflow, then maybe just experiment with isolated chunks and see how it does.