When you run the above application, you see a general workspace with many different menu items:
Each of the main menus produces a different dialog for handling some data:
The benefit of the current state of the application is that (1) it is well organized, e.g., all the forms in the same package, and (2) all the forms are designed in the Matisse GUI Builder. These two decisions will definitely simplify porting to the NetBeans Platform.
Now, what's the first step in the porting procedure? Simple. We need to identify who the users of the application are. What are they doing with the application? Do all the users need all of the features? Based on the answers to these questions, we can decide where the module boundaries will be. It would be useful to the end user to have only those features available that are actually needed.
What if all features are needed by all users? Then we should determine module boundaries in some other way. Maybe we should identify a workflow in the application, with each step in the workflow being provided by a different module (or set of modules, i.e., a cluster of modules).
Definitely, there could be one single module containing all the entity classes. Then all other modules would depend on the entity module (i.e., this would be the model of the application, providing the API that the rest of the application would implement), without depending on each other. That would result in a modular loosely coupled application, which is the ideal endpoint of a NetBeans Platform porting procedure.
Either way, in rearchitecting this application from monolithic to modular, the above concerns are the first that should be addressed before any other. Probably, after that, we could look at how the NetBeans window system can be leveraged to better organize the UI of the application, i.e., the JPanels in the various dialogs could be displayed in TopComponents instead, each provided by modules dedicated to the feature for which they have been created.