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.
Best Answer
Typically, business rules are of the form "if(condition) then action", while business logic tends to describe a larger set or a sequence of both business rules and other logic. So "business logic" is more general any code that implements logic specific to your problem domain, where "business rule" is a specific concept.
Examples (pseudo code):
No, you don't have to learn UML. But it may help to visualize your solution, and in fact make it easier to describe because you have to think it through more thoroughly - if you can't draw it in UML, probably something is not quite right yet.
Business rules can be nicely described with state charts or activity diagrams, and business logic in general can be described in sequence diagrams or activity diagrams.
It shouldn't - if it does, this may indicate poor separation of concerns. MVC is a way to organize your code, or more specifically to keep aspects of your implementation separate (aka 'separation of concerns'). The M(odel) in MVC is what should implement your business logic.