I work on a large old (15+ years) Windows desktop application.

The applcation is a Frankenstein of legacy technologies: (ATL and ADO for db, .NET and COM with some legacy VB6 for business logic, mainly VB6 for UI).

Multiuser is implemented by direct access to the DB.

The application doesn't have good design guidelines. The UI is the worse of all.

We need to migrate to multiplatform quickly with little human resources. It also needs to be progressive (ie, we need to show something working fast). Rewriting is off the table, so the next best thing seems to be split into a fat backend running the existing codebase and writing a lightweight frontend.

The only way I can think about this is generating an abstraction layer to unify all the business logic into a common interface that encapsulates everything, and exposing that through an API.

But I'd like to avoid the pitfalls of just making a headless client mirroring the current UI and exposing that through Asp.Net

So, I'm looking for approaches on dirty migrations of UI applications, that make this work the best as possible. Suggestions would be helpful for both, encapsulation of the current codebase, and re-design of the new UI for cloud over the desktop one.

  • All UI migrations are dirty migrations :) More seriously though, I don't think there's a silver bullet out there for you. "Quickly with little human resources ... show something working fast" sounds like some nasty higher-level management restrictions. Working on new UI components with a fat backend build of legacy stuff sounds like a decent enough approach to me... somewhere to start, with visible progress, and leaving you able to swap out the API's backend at a later time... theoretically! – jleach Mar 12 '19 at 14:43
  • 1
    "Rewritting is off the table" - You're porting a 15 year old app from desktop to the cloud, and changing the UI at the same time. Seems like a 're-write' to me. – Graham Mar 12 '19 at 18:57
  • @Graham: Sure, but that's not my decision. – xvan Mar 12 '19 at 19:17
  • @xvan My point is that you ARE basically doing a re-write already, in terms of thinking about the size/scope of work. If management is thinking that this is less work than a 're-write', you probably need to work towards adjusting their expectations. – Graham Mar 13 '19 at 17:53
  • 1
    Whole books have been written on this subject, which makes this question a poor fit for StackExchange's Q&A model. As a suggestion, look at Fowler's Refactoring, which was recently updated to a 2nd edition. Closing as too broad. – user53019 Mar 16 '19 at 15:02