Your primary difficulties I feel are that you have a mismatch between a very linear and custom workflow in an older application that do not coincide with the user interaction workflows that are common on the web.

Web applications that interact with a server application that contain the business logic communicate in a Request/Response messaging style. The client browser and the server running an application that has the business logic are separate processes. The client requests a resource (html page, jpg image, JSON data, etc…) and the server provides that resource in an inherently stateless way. This is a much different paradigm from your self contained desktop application that has a concept of global state for a users session. The users session in a desktop application lives and dies by the running process on the workstation.

So basically there are two ways you can handle the maintenance of state in a web application that always has a client/server relationship.

Server Centric

A server centric web application will maintain stateful information for an individual user’s session. They do this typically by serving a session cookie once the user is authenticated. The client application (browser) will include its unique session token with each request which allows the server to retrieve stateful information about the clients state from the last time they received a request for this client.

Further the server will contain most if not all of the business logic behind performing actions that the typical business user will want to achieve, actions that have real business value. This is not to be confused with presentation logic which is most client side code (Eg. Javascript) that performs user interface interaction like hiding a particular menu in a form if a specific checkbox has been checked.

Client Centric

While you might have a server to maintain authentication of a user and maintaing an active session, you could use a client side scripting framework (Eg. Javascript framework like AngularJS to perform most if not all of the business logic operations and presentation logic operations. The advantages of this model are that you can program your web application in much the same way as one might program a desktop application. Client state will live and die by the browser navigation to the current page in much the same way that it will live and die on the running process of a desktop application. For communication with a database you can expose stateless webservices on the server that can proxy for a database.

Some important considerations with this approach are that users on client browsers have the ability to modify or change how Javascript can behave which might be potentially dangerous and introduce unknown exception cases to your application. It is highly recommended that if this approach is taken that great care should be taken on interactions with servers to sanitize inputs and validate all data going back and forth.

Summary

In summary, the application you specified is very old. It sounds like you are making the right choice in capturing the current workflows and trying to assess what the user needs are. The next step would be to try and follow Agile principles and capture business value in user stories. I would start on clean slate and try to discover other means and workflows that can also attain the same business value captured in the user stories. This application is so old that it was likely limited by the technology of its day to where technical constraints influenced the user workflows in a negative or archaic way. Basically there are probably better ways, more intuitive workflows and user interfaces that the business can use that will also achieve the same end goals.

Read up on asynchronous programming

It sounds like your original desktop app was tightly coupled with the GUI with functions not continuing until user chooses decisions from popups.

The web, and many GUI frameworks, just don’t work like this – all operations that may require user input have to provide a delegate/callback so that processing can continue.

It’s really not that bad, but a massive change from your current design. IMO it’s worth your time to break down your current design to support asynchronous programming, regardless of Web or GUI toolkit.

This http://www.unigui.com/ seems relevant. This seems also close https://forums.embarcadero.com/thread.jspa?messageID=510208&tstart=0. I guess your old “business layer” code is written with Borland tools, either C++ or Delphi?

Some decade ago I was porting lots of legacy code from 16bit DOS (Turbo Pascal) to 16bit DPMI (Borland Pascal) and to 32bit Windows (Borland Delphi). In order to port the DOS part as-is without breaking anything (rewriting the code was not an option, just small refactorings) first thing I had to do was to create a “DOS terminal emulator” placed as a component inside a Windows GUI surrounded with 32bit Win32 API and new Windows components etc. Though it seems different, the way DOS application works with user input through modal dialogs etc. is totally different from how Windows event queues work. The emulator arranged things by running the DOS emulator in separate thread – all user I/O functions redirected to the emulation layer which in turn suspended the DOS thread when waiting for an Windows event. The DOS code and its logic was not changed (broken) at all.

In your case you can also get out gracefully by first creating(using) an emulator like JSC C# → JavaScript http://jsc.sourceforge.net/examples/web/CardGames/fx.FreeCell.htm. Once you can run your application “in the browser” you can add the required advantages (“..mobility, possibility of selling SaaS versions, modern look and components …”) one by one

I don’t know which technology would be best suited for your legacy server-side language (the GUI-dependent business layer). But the running in the browser technology is already here, building on asm.js as the web processor, see e.g. https://isocpp.org/blog/2013/03/cpp-to-javascript or quite long list of tools that can be used to convert legacy code to be run in the browser at https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS

Disclaimer: I am not a super experienced web developer.

I believe that javascript/the client side of web apps are not usually written this way, as no matter what, in most browsers all js code is run in one thread. However, you can simulate this behavior, with something like this (I have never used it, it’s just what I found), to pause a thread (pseudocode):

var stuffIsDone = false

doInAnotherThread(function () {
    // blah blah blah, do stuff, load purchase, talk to server, whatever

    // ...
    stuffIsDone = true
})

// DO NOT PUT THE BLOCKING WHILE LOOP IN THE MAIN THREAD, IT WILL FREEZE THE INTERFACE
doInAnotherThread(function () {
    while (!stuffIsDone) {} // Do nothing until stuff is done

    // stuff has been done, do whatever
})

  > Reworking/rethinking these workflows is not an option

I am afraid you have to add additional states in your workflow, every time the old workflow asks for a user-decision without changing the base workflow.

example in old system:

customer adds products to basket
...
checkout: customer decides to buy the content of the basket
system does the verifification
    order article is out of stock
        messagebox: "do you want to (a) cancel the order, (b) remove this product or (c) select another one equivalent"?
            (a) ...
            (b) ...
            (c) ...

so instead of showing the messagebox the intermediate-workflowstate: “One or more articles are out of stock is reached.”

alternatively you can introduce the intermediate-workflowstate “order can not be processed” with additional infos for those items that have problems.

in a classical web app the customer is redirected to basket-overview-page where errormessages are displayed next to the order-item that has problems.

@JBRWilkinson is right, basically.

Having a web client front end and a web server backend is a highly asynchronously thing by definition. Especially when callbacks come into play to dynamically load data or verify things, etc.

But you don’t have to rewrite the whole app. You don’t need to rewrite the workflow either. You “only” have to work on those parts that deal with the UI in any way. I write “only”, because this can be still painful enough, especially when all the logic is tied into the GUI forms. Been there, done that.

We have made good experiences through this process by pulling out UI code into shared code parts, abstracting the UI away. Thos code parts are used from both the Desktop GUI and the web backend. While the GUI still uses controls etc. as usual, the web backend dynamically renders pages or delivers JSON to the client based on those information. The client consists of a good portion of script code to control the web UI.

Was quite a bit of work and took some serious refactoring to do that transition, but it was worth it. And you learn a lot about good and bad software design along the way, I can tell you that.