This section should provide a kind of cookbook or checklist approach for porting applications. It's especially important to point out the non-obvious changes (i.e. ones the compiler won't scream about) and offer guidance on how to deal with those changes.
The immediately obvious changes, and ones which your compiler will loudly complain about, are those related to the new FX namespace, and renamed classes and member functions. Start by correcting these.
In the interest of avoiding future weird debugging sessions, you should probably take the time to add the appropriate casts to and from FXival and FXuval. Note that if you don't make this change, your code should continue to work as it always has, but it may also leave it susceptible to unexpected problems in the future when ported to some 64-bit platfoms.
If you're sorely missing the FXApp::getMainWindow() function, get over it. The solution is to save a pointer to your application's main window in a global variable (or some other accessible place) and replace all calls to getMainWindow() with a reference to this variable.
If your application was sending the ID_ICONIFY or ID_DEICONIFY messages to a top-level window (e.g. the main window), or if you were calling that window's iconify() or deiconify() member functions directly, you can probably just modify the code to use the ID_MINIMIZE and ID_RESTORE messages (or the minimize() and restore() member functions) instead. To be sure, read the section on Changes for FXTopWindow and FXMainWindow.
If your application uses the MDI classes, be sure to read the section on Changes for FXMDIClient and FXMDIChild and understand the implications of those changes.
If your application "handles" the SEL_CLOSE message from its main window, be sure to read the section on Changes for FXTopWindow and FXMainWIndow and understand the implications of those changes.
If your application uses FXMenuCommand buttons that are either "checked" or "radio-checked", you need to replace those with instances of FXMenuCheck or FXMenuRadio, respectively. One particular concern (that the compiler won't catch for you) is that the basic FXMenuCommand widget no longer changes its state (or draws itself any differently) if you send it the ID_CHECK or ID_UNCHECK message, so be sensitive to those cases as well. For more information, see the section on Changes for FXMenuCommand.
Since the FXGroupBox widget no longer enforces radio behavior for FXRadioButton widgets, you will need to make some other provision for keeping the state of these radio buttons in sync. The recommended way to handle this is by using a single FXDataTarget as the message target for all of the radio buttons in a logical group. For more information, see the section on Changes for FXRadioButton.