Migrating to HTML5 Part 2

Ok, it's all very fine and dandy to talk about the case for automated migration from .NET to HTML5 as a way to reuse proven code, but what are the real economics here? Are we talking about a lot of savings, or just a tiny improvement?

First of all, let's agree on some terms:

Migration: a process whereby an application is moved from one platform or language to a different one. The implication here is that the new app is functionally equivalent to the original app. Normally this process is done through some kind of automation, for reasons discussed below.

Rewrite: Creating a new version of an existing app but starting from a clean slate. There may be some code reuse, but the resulting app may be quite different from the original app, although the business purpose will be the same.

Business purpose: The functional reason for a custom application. The purpose of an app might be to manage inventory in real time, for example, or to provide a dashboard to management of supply-chain status.

COTS: Commercial off the shelf software. This could be SAP, or SharePoint, or Salesforce; it's any software created and sold by an ISV. May or may not be customizable.

KLOC: Thousand lines of source code. While admittedly counting lines of source code isn't the best way to assess app size or complexity, it's easy, familiar, and everyone understands it. When I refer to KLOC I'm assuming a number after subtracting comments and redundant code.

Second, let's agree that comparing a migration to a rewrite is comparing apples and bicycles. Here's why:

A migration yields a functionally equivalent version of a legacy app. A rewrite yields something entirely different, because no one starting with a clean sheet of paper will create an identical version of an existing app in a new platform. It would be criminal. With a clean sheet of paper, you're morally obligated to consider all the compromises the legacy app included and all the new features people are clamoring for that never got implemented. So while the business purpose may remain unchanged, the app itself will be a different app.

And there's a second reason.

In the old days (like last week) a lot of IT shops were dealing with modernizing legacy apps without fundamentally changing their paradigm. If you were trying to get off VB6, you didn't also get off of Windows. So maybe you went from VB6 to VB.NET, but it was still a desktop app. Mouse, keyboard, large monitor. Rich UI. Persistent network. 

Today this would be at least rare, if not unheard of. What I hear from customers is if they want to get off VB6 they want to wind up running in a browser. They want HTML5 and JavaScript and everything that represents. 

• Maybe they want a mobile version.
• Maybe they want to support BYOD by their customers or employees.
• Maybe they want to simplify deployment of new releases.
• Maybe they want a more agile process with updates monthly instead of semi-annually; pushing new desktop apps out monthly could be expensive.

Welcome to 2015

It's a brave new world. In hindsight, the desktop was pretty straightforward. In comparison, a modern web app is pretty complicated. Things that were dependable on the desktop might not exist in a web app. You don't know what OS you're running on, or what browser, or what hardware is under the hood. What services are available? What HTML goodies are supported, and how well? Is there a network connection? What happens when it degrades or disappears? What about authentication, security, form factor, printing?

In the old days you could whip out an app with some Windows controls for the UI, event handlers, some business rules, a nice database connector and go to lunch. Maybe pull in a third-party library for some charts and graphs. And it would work great.

Now you need a lot more: session management, state management, load balancing, app servers, responsive design, maybe cloud stuff. You need a way to monitor your app health and client responsiveness.

Wow that got big fast

All of this takes a lot of code. That 10KLOC Windows app re-created as a well-designed web app will be a lot larger. 

Hello World in C#/.NET is 150KB on disk; Same app as an ASP.NET/MVC app is 67MB of source code. Why? Well, for one thing, a lot of libs get included that you may or may not need. With pure .NET you don't really think about the runtime sources as part of your project (and .NET is HUGE); with a web app you have things like JSON, jQuery, Knockout, and more.

And the pattern adds to the size and complexity. Instead of referencing, say, a button directly you will reference a view model of the button--on both the server and client sides. And then a controller will decide what to do with it. 

Here comes the bicycle

Basically this is why rewrites are such a terrible idea, if they can be avoided:

• You're going to get mission creep: new requirements, new features, more stuff
• The basic architecture of a web app is huge compared with a desktop app; more code to write.

So if the "banana" is a 100KLOC VB6 app and you want to migrate it to the web, estimating how long it will take to write 100KLOC of web app code isn't the right thing to compare it to. The "bicycle" is more like 300-500KLOC or more of (assuming you want to stay in the world of Microsoft stack) ASP.NET, jQuery, HTML, CSS, JavaScript, JSON, Angular/Bootstrap/Knockout/KendoUI/pick-your-framework code.

With a migration your 100KLOC VB6 app will still swell to a much much larger size, but the advantage is that you won't have to write any of that code, or even touch it, except to clean up issues that arise from incomplete object transformations, syntactic mis-alignments, or paradigm shifts. You can focus your energies on rolling out a migrated version of the existing app, getting a quick return on the migration investment, while your dev team works on adding new features to this modern code base.

In the final installation I'll show some examples of real-world cost comparisons.

Need help figuring out whether or not your app is a good candidate to move to HTML5? Let us help! We'll develop a free proof of concept and show you what your app looks like on a mobile device. Click below for more info: