Hi Vladi,
Yes we use DevMode and Plugin Mode extensively.
Sure, I can provide our plugin rewrite journey as case study.
Recently we had rewritten our flex plugin to HTML5 plugin using new HTML5 JS API(local) SDK using plugin seed v1.0.0 based on Angular 5 and Clairty v0.11.
As part of this effort, we had implemented a REST API layer to cater the UI calls. Due to devmode we were able to de-couple the dependency between plugin(UI) team and backend API team.
Hence, both effort went in almost parallel. Plugin team used json-server and implemented the UI and able to write unit testing as well. At the end of subsequent sprint both backend and UI get integrated. 
Whenever we propose the migration to new framework, the very first question we have been asked by the management is cost and effort estimate which will be always high without proper framework/tooling from VMware. So, partners will stay on the same architecture as it does the job.
This is where VMware can focus and provide tooling like plugin seed which gives clear picture for teams to assess and project the effort to the management with confidence.
Driving factors for Remote Plugin based Plug-in seed:
- Dev Mode for rapid development/debugging
- Unit testing/code coverage (CI/CD)
- Latest stack (angular 9/Clarity 3.x)
- Easy debugging/Fixing UI specific bugs
- Partner presence in Cloud based VMware products
we all know how much time it took for our customers/partners to move to HTML5 Client which is a great client compared to flash one.
Hope this could be avoided in case of remote vs local architecture.:smileygrin:
Regards,
Kumar
Hi Kumar,
This is a nice overview of the Dev process and I will share this with PMs.
There are different considerations at play here so we have to strike the right balance:
- Partners migrate to Remote plugins because they are better in linked environments and in the Hybrid Cloud world, not because they are forced to migrate away from a dying Flex Client.
- Remote plugins were designed to use mostly the same set of frontend APIs which means you can reuse the UI you already developed (just move the UI to be served from your backend).
In a way you can keep using the Plugin Seed in standalone mode to develop the UI. For Remote plugins you just need to change how you package/deploy the UI on your appliance, not how you do web development.
Based on this, the approach you have specified works well if you are building a plugin UI from scratch (which you had to do for Flex -> H5 migration). For partners building Remote plugins from scratch we might consider providing Plugin Seed-like tooling.
Nevertheless, most partners (like yourself) would rather need Local-to-Remote plugin migration tools to achieve exactly time-to-market requirements your management wants. Hence, in latest 6.7 releases we shipped the SDK with Local-to-Remote plugin conversion tools:
- Migration To The New JavaScript API manual guide and automatic tool (migrates Bridge API calls to new JS API calls)
- Plugin Manifest Converter tool (migrates plugin-package.xml / plugin.xml to plugin.json manifest)
It would be great if you have any feedback on these (though you probably don't need the first one).
There is also the possibility to do Standalone UI to Remote plugin integration which some partners prefer.
In summary (for your management ): Migration to a Remote plugin is a lot cheaper from UI migration perspective. It might take more effort only if the Java middle-tier has been heavy (which was not recommended for local plugins anyway). Always happy to jump on a call and discuss details and feedback if needed. 
Cheers,
Vladi