Primarily, these changes are in three areas: communication with user interface controls, reporting and graphics.
Communicating with User Interface Controls
Although the user interface controls in our web framework are for the most part very close to their desktop equivalents, they don't share any code with those desktop equivalents. As a result, they are not the same classes under the hood so you can't have code that directly talks to both a desktop pushbutton and a web button. So the first thing you have to do (if you haven't done this already) is separate this code from the UI.
I have started porting a desktop project to the web recently. The project is a very fancy calculator of sorts. The user fills in 10 or so fields, chooses some options and the app calculates the advantages of doing one thing instead of another. The window is filled with methods, each of which is essentially a formula. Anytime the user changes a value in a field, a bunch of these methods run and update StaticText controls that show the results. Since these methods can be directly accessing controls (even via parameters unless I only pass in values), I have to change the way the methods get their data.
To port this to the web, I created a class (which I called "scenario" since one set of data and results is a scenario in this case). I moved all the methods to that class and then created properties for each of the fields on the window. I added a property to the window that holds a reference to a Scenario object and I create that object in the open event of the window. The fields now just update the properties and the methods use those properties rather than the fields themselves. Once I was sure that worked and produced the same results as before, I made the class an external file so I could share it with the web project.
Once I had made this change, I imported the Scenario class into my web project and added code to the controls on the page to update the same properties. So if you have your code and UI closely tied together (as I did), you will need to separate them first. You can do that today in preparation for building your web version. Incidentally, this kind of separation is just good design as well. And by using the class as an external item in both the desktop and web projects, I can fix or enhance the code in this class from either project.
If your desktop project prints, then you'll need to take a different approach for the web. Printing for a desktop project means drawing into a graphics object or using the Report Editor. Using a graphics object isn't a great solution for the web because you can't send it right to the printer. You would have to display it on a page. Sending page-sized graphics over the internet is not a great idea regardless of what tool you use to build your web app. And the Report Editor is not supported for web applications right now. The best solution is to create a page which you lay out for printing. Then you just fill in values, most likely into labels (the statictext control of the web framework) and present the page to the user. They can then print the page directly from their browser.
There's not much in the way of overhead when it comes to using graphics in a desktop application. In a web app however, the varying speeds of the Internet between your app and the user's browser, will impact the responsiveness of your app so you need to be thinking about how to optimize when it comes to sending large amounts of data from the app to the browser. Large pictures will be time-consuming. You can make them smaller by using JPEGs. But if possible try to avoid using pictures. There are other ways, in some (certainly not all) cases, to use controls such as rectangles combined with styles to create graphics that are smaller and can be cached automatically by the browser. For example, to create a monthly calendar, use rectangles and labels rather than drawing the whole thing in a big picture.
In summary, there are some things you can do now to start preparing your desktop project to become a web project. There are also things you can start thinking about in terms of how you will approach printing and graphics in your web application. It's going to take some trial and error to find the techniques that make the most sense for you.