Microsoft released Silverlight 5 but there has been no news of any future versions (except service releases) being released. Combined with the increasing visibility of HTML5 and modern JavaScript libraries it now makes a lot of sense to start adopting the new and emerging technology instead of relying on Silverlight whose future is in doubt.

Given this what are the migration strategies that you are using to move away from Silverlight? Any lessons learnt so far?

  • 1
    Depends, first of all, it would be helpful if you could either point us to your current site, or simply specify some of the requirements (Form Heavy? Videos? Lots of Animations?) – Ivo Wetzel May 27 '12 at 19:20
  • @IvoWetzel, It's an intranet application. And yes the application is form heavy with hardly any videos or animations. Silverlight is used to develop few input forms which are pretty heavy. We also use the deep zoom functionality in another part of the application. In its current form there is a mix of HTML and SL. I would ideally like to have less dependency on SL going forward, so for any new functionality we want to stick to HTML+JS. – SAK May 28 '12 at 2:36
  • 1
    @Joe Silverlight is great for LOB intranet applications. Everyone has Internet Explorer in corporate world, and it provides a desktop-ish experience in the browser with a very nice MS development toolkit. – Kirk Broadhurst May 28 '12 at 6:10
  • So you've got standards for CSS, JS and HTML that even IE has taken somewhat seriously for 10 years now. Making it work with those means you're going to have an easy time porting to mobile, Linux browsers, Mac browsers, desktop gadgets, Google gadgets, anything you can stick webkit into, including iPhone and Android apps and you're going to pay for the MS-owned proprietary technology that only works in Microsoft products because wubba? – Erik Reppen May 29 '12 at 21:34

Yesterday it was Silverlight, today its HTML5, tomorrow who knows.

Which ever way you cut it, you will need to "port" it. Porting will always be a manual affair.

In terms of "strategy" just make sure your design is modular, clean and highly structured code. When the day comes to port. If you can see and understand the design. The porting pain is just that little less.


You don't abandon a technology because there are no updates for it. If you have invested time and money to build the software and it is working well and the software publishing company is committed to it, leave your application as is. Panic if the software publishing company declares that it is not providing support on any commercial platform. By the time you migrate your application, the life time of your software could be close to an end and who knows, another flavor may come along. In short your shop should establish a migration policy and not rewrite the software with every new technology unless there is a business need for it.

  • Except nobody owns JavaScript and HTML5. They are standards built off the old standards that everybody has agreed to try to work with. You don't always have equal access to the latest features on all platforms but code from 2002+ is still likely to be of some utility today. You can't say the same of Flash or Silverlight. The real question, is why would you go with proprietary technology in the first place when HTML5 is nothing more than what HTML, CSS and JS have been for years now with a handful of new bells and whistles that IE is finally supporting. – Erik Reppen May 29 '12 at 21:10
  • Correction: "starting to support." Most of the old bells and whistles were supported but we've been waiting about 10 years for them to get on board for a lot of the newer stuff, which is in fact mostly quite mature in web-years. – Erik Reppen May 29 '12 at 21:36
  • @ErikReppen, thanks for your comment. The state of Silverlight today. In a short time it moved from a zero to a hero then the unexpected happened. Not many people could have guessed this. You point about HTML and JavaScript is valid but they have their pains too. You can get much cleaner code in SL and C# that what you'd get in JS and HTML. At least I think so :) – NoChance May 29 '12 at 22:31
  • 1
    In JS, architecture is your problem to solve but there are now many libraries out there that help with that and many years of vociferous client-side developers getting serious about architecture and best practices to guide people. JS's success isn't an accident, IMO. It's easy to make a mess with but it's also easy to set a paradigm with it and stick with it. Ultimately, it's an exceedingly powerful and flexible language when you know what you're doing with it. – Erik Reppen May 29 '12 at 23:03
  • I like your point "it's also easy to set a paradigm with it and stick with it", it is a good idea in any language not just JS. – NoChance May 29 '12 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.