Question

Are there any good books or websites on this subject covering subjects like:

  • different migration scenario's (big bang, module for module, function for function) pros and cons
  • do's en dont's
  • tooling
  • handling customer expectations

We have a rather large winforms based product which we would like to migrate to the web. Migrating in a 'big bang' scenario would probably take at least two years. We're looking for alternative scenario's. I'm especially looking for ways to handle the inbetween scenario, what options do you have to keep customers happy.

  • Let them use the windows application at the same time as the new web application?
  • Let the windows application use the new features from the web application via a service interface?
  • Accept the cost of double maitenance for a while to keep customers happy?
Was it helpful?

Solution

Based on our own experience with moving applications from desktop to web: carefuly inspect the architecture of your winforms applications and if possible - try to provide a web interface at the service or persistence level so that your windows applications use web services instead of directly talking to the database. Then you can let your users launch desktop modules from the application server using clickonce.

Such approach let us move to web quickly and users got the same GUI and a new way to access the application. In fact, it took like 3 or 4 months to redesign existing applications so that they use web services.

Then, we were replacing modules one by one, implementing them as web applications and maintaining both (clickonce and web) for a short period of time so that users were able to get used to new modules.

The migration of consecutive modules from clickonce to web was prioritized in an obvious way - we've started from modules that were used by most users. In fact, the initial release of the system has only one web forms module ready and remaining modules are being replaced for over 2 years now, one by one.

OTHER TIPS

You are more likely be doing a complete rewrite. Because web is conceptually different from windows forms, there would be a lot of changes.

Your best bet is stop new development on windows forms app. Start writing a new app for the new features. Then start moving one isolated feature at a time to web.

You have two options for the UI

  1. webforms - matches closely with windows forms model. If you are using any 3rd party controls like devexpress, you can find the equivalents in webforms.

  2. mvc - It is more like re-architecting the whole presentation layer. If your UI layer is already separated from business layer, then it would be a good choice to go down the path of MVC. However the development experience is totally different from doing windows forms.

State

  • Maintaining application state is comparatively simple in windows forms. In webforms you have viewstate to do that for you. But you are going to run in to rude shocks as you run into limitations of viewstate, especially when it gets too large.
  • In MVC, you are completely responsible for maintaining the state.

New skills

You require new skills to mimic state-full scenarios

  • Strong understanding of javascript, ajax, at least one javascript framework like jquery. 3rd party commercial tool kits can ease some of these pains.
  • Depending on complexity you might need web application frameworks like Backbone.js /Knockout

Expectations

It would be very expensive to achieve the same responsiveness as windows app, as you will be messing with multiple technologies. Probably your users are going to hate the new app initially. Having skilled web designers on staff is very important

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top