Layers
The solution you are looking for is known as layered architecture. When you separate your system into layers you are seeking some advantages like independence and reuse. What is the main disadvantage? More work to build and more "duplicity" of code.
A popular layer model is the 3-tier model, where you have the presentation layer, the business layer, and the data layer. Each has a well-defined goal and this allows you to "swap" one layer without having to rewrite the other. Realize that this is a logical separation and does not always mean a physical separation.
In theory, this means that each layer will be completely independent and for this to work you need to work on the concept of "interfaces". This means that the communication between one layer and another needs to be clearly defined for the two ends that will communicate. Then you will have interfaces between the business layer and data and another set between the presentation layer and the business layer.
Having the business layer does not mean that you will always have business rules applied to the data, but communication between the presentation layer and the data layer does not occur directly, without going through, even without any layer of business.
This article can give an introduction on this subject.
In your case, you are creating your presentation layer using Windows Forms. The other parts of the system should have no dependency on this technology, ie if some business or data access class can not be removed from the Windows Forms project and run in a Console project, for example, its layers will not be well separated.
In a practical way, working on all 3 layers means you would not have any code with business rules or database connection within forms. In order for the form to be able to save its data, it would need to pass that data through an interface known as the two layers. The same should occur between the business layer and the data layer. It is also very common for systems to couple the business layer with the data layer when there is no concern about changing database vendors, for example, but as I said at the outset, it is always a matter of choice that will bring advantages and disadvantages.
Regarding your concern to reuse the code that is in the forms to the maximum, if you have already separated these parts above, the next step would be to choose or develop a technology that could generate your forms from a set of metadata . This metadata-based architecture allows you to generate forms from some declarative information, something like XAML . You can use something ready or build one yourself. The central idea is that from these metadata you would be able to create your forms for both Windows Forms and Web.