I am very sorry to say that I am not aware of any easy way to make the transition from a Java-rich GUI to uifigures. All the main UI components are available (and then more), but many customizations of the components that are possible in Java are missing (for example, Border, Renderer, Editor etc.) not to mention the 30+ Swing callbacks for mouse/keyboard/action events that make Java GUIs "come to life".
In addition, there are simply too many fundamental differences that [IMHO] would foil any automated conversion attempt. For example, uifigure [still] do not have toolbars, toolstrips, customizable icon, or non-pixel units (esp. normalized).
Moreover, the fantastic GUILT (GUI Layout Toolbox), on which many existing GUIs depend, still does not have a uifigure variant (the new grid layout/container fills much of the need but a one-to-one variant of GUILT would remove a huge amout of necessary rework).
The bottom line is that [at least at the current time] it looks like users need to manually redevelop their uifigure GUIs. Even with this manual redevelopment, we are severly limited in the new uifigure's customization compared to legacy Java-based UIs. Hopefully these limitations will be resolved over time, leaving us with just the benefits of uifigures over legacy figures (there are many of those as well, don't get me wrong).
Nobody should really be upset about this: we all knew that using undocumented Java in Matlab GUI carried a risk and would not last forever. It worked well for nearly 20 years (and possibly for several more years in the future). This is longer than the lifetime of most tecnologies - How long did DOS programs live before they had to be redeveloped for Windows, then again for the web, then again for mobile? In fact, Matlab's Java UI lifetime may turn out to be longer than the future lifetime of uifigures, before we will need to redevelop our GUIs yet again to fit some future new technology.
Speculating about the future, I hope that MathWorks will make a gradual transition i.e., first remove GUIDE but keep Java GUI running, then (in a subsequent release) make uifigure the default figure type but keep legacy figures running, then (in another subsequent release) remove the Java dependency in all of Matlab but still enable legacy Java-based GUIs to run using either the built-in JVM or (when they stop shipping Java) a user-installed JVM. Such gradual steps will make the transition from Java to web-based UIs much smoother over time and will allow users enough time to (re)develop the UIs without time pressure. The business benefit to MathWorks will be that users will keep upgrading their Matlab release, avoiding the debacle of R2014b in which many users stopped upgrading and stuck with 14a since the new HG2 broke (or froze) their programs. Having said that, MathWorks has many business and R&D considerations that I am not aware of, so they may decide not to follow my suggested gradual transition path: we might discover that R2020a brakes all legacy Java GUI - I hope not, but I really have no idea.