3 Questions to Ask When Migrating from Desktop to Web

With modern web frameworks cropping up more and more frequently, development and product managers are struggling to know when to jump in and update their legacy applications, what the right reasons are for the transition, and how to move over without creating pandemonium. This post seeks to lay out general guidelines for anyone to follow to ensure a smooth upgrade for both their development teams and their users.

With web applications undergoing a renaissance over the past decade, many individuals and companies are wondering what the proper course of action is, and are hesitant to jump in, lest they repeat the mistakes of past rewrites. In this post, we'll be discussing the questions to ask, the checkmarks to check, and the path to follow in order to make an involved effort simpler to understand.

Why are We Doing This (again)?

For many companies, moving to the web seems like something they should do, rather than something they need to do. That is, they see the modern web movement in the world of development and don't want to be left behind, but haven't fully analyzed the need within their particular sphere. Understanding the reasons for moving, and then assessing your situation, will help determine if a need actually exists.

Competition

One of the biggest drivers of improving software is market influence - complacence in innovating is a quick way to lose market share. If your competition has a more modern, more available, and more user-friendly application supporting their business, your revenue will feel the impact. This is readily apparent with external applications that have a direct effect on revenue - a web application has a lower barrier of entry than a desktop application, and if your users can open up a browser and begin using a competitor's product in seconds, you will lose customers who value ease of use above other metrics. For internal applications, the impacts aren't quite as noticeable - aging internal applications will eventually affect productivity and efficiency, which will impact revenue through higher costs. The excuse of "it still works and we can't afford to replace it" will eventually catch up to your organization as your competition implements more streamlined tools and processes.

Hardware

Aging hardware can slow down both web and desktop applications alike, but significant changes to web applications get filtered through a relatively consistent tier of systems that spread out the processing needed to get work done. Desktop software, due to the processing that inherently occurs right on a user's machine, represents a higher load and becomes more susceptible to the limits of the CPU, RAM, and data drive speeds. Because of this, upgrades to desktop software can force that hardware into obsolescence, whereas new versions of web applications can focus their increased computational needs on the server, keeping the processing on the browser end to a minimum. This results in applications that can run even on fairly low-spec machines, thereby increasing the potential customer pool.

User Base

Remote workers, either permanent ones or just ones who venture out into the field often enough, can have their efficiency driven down by desktop software either by updates that are mandatory or cause workflow disrupting issues, or simply because they aren't local to a machine that can run what they need. This point lends itself to the prior two motivations, as all three reasons can culminate in lost productivity. When thinking about external customers, however, a migration to the web opens up an easier path to transitioning to a Software as a Service (SaaS) model.

Current Technology

Desktop software, both internal and external, can suffer from obsolescence of the underlying frameworks in which they were written. Finding developers who still remember the language or platform – or worse yet, trying to find someone willing to learn it in order to support it -- becomes more and more difficult as time ticks on. Even if you have the staff on hand to support older applications, when newer applications (written in modern frameworks) are added to their workload, bug fixing and general support increases in difficulty as team members start having to split their time across platforms, wasting precious time due to ramp-up. Older software for the most part also tends to be inefficiently written, becoming a patchwork effort from teams of developers that have come and gone. Performance can suffer in ways that can't be rectified without a complete rewrite due to the architecture (or lack thereof).

What is This Going to Do for Us?

We've talked about the reasons for moving to a web application, so now let's think about those reasons in terms of benefits to the organization.

Devices & Performance

Web applications allow for access from basically any device, without a need for a VPN, which opens up support for most operating systems, whether desktop or mobile. Our hardware motivation above turns into an opportunity to greatly expand the number of devices you can support, with tablets and phones entering into the equation for specific workflows. This can increase the audience for external applications, as users are more likely to use your software if they can access it from more locations and with whatever hardware they happen to have on hand when they hear about it. For internal users, web applications allow them to be more responsive when emergencies crop up, or when you want to provide greater flexibility on where they work and what they use. Migrating an internal application to the web necessitates moving your data into a more accessible form, which provides the opportunity to put your data into a distributed setup. This will lower latency for offices that aren't collocated with the information they need access to.

Deployment & Flexibility

With web applications, the hassle of scheduled, voluntary, or mass forced rollouts are a thing of the past. Once the application has been certified for release through internal testing, it can instantaneously be pushed live. This benefits both bug fixes and new feature implementations, allowing urgent issues to get addressed in smaller amounts of time, and providing more flexibility and immediacy for new functionality. If smaller rollouts are desired, it becomes easier to determine which pool of users get access, granting another level of testing for new features. And to the inherent structure of modern web applications, better adherence to best practices is enforced, making it easier to switch out frontend technology in the future if the need arises.

How Do We Do This?

Once you've asked the above questions and the answers look like they'll address issues currently plaguing your organization, determining a proper plan of attack is key in making sure this rewrite is done once and done well.

Define an Approach

The two options available to anyone migrating an application are to convert it as a whole or move it over piece by piece. Both approaches have their pros and cons, so let's dive into them.

The preferred approach is to do this as a whole. With the importance and value of a proper UX process gaining visibility and recognition within the development community over the past decade, chances are the current desktop application was not designed with usability in mind. Moreover, simply migrating the desktop UI as it stands will lead to a poor experience in most cases (depending on the complexity and current design of the existing application). Designing an application workflow by workflow prevents both designers and developers from planning ahead and architecting for cohesion. Prefacing your development with a full UX process of user research, interaction design, visual design, and user acceptance testing will allow you to create an application with high usability and high usefulness, with a modern look and feel.

The cons of this are fairly obvious -- a design process will take a lengthy amount of time (again, depending on the size and complexity of the application), with zero developed code being produced until it completes. If your organization is pressed for time, then this method will likely not be a good fit, unfortunately.

The other option is migrating the application piece-by-piece. The advantages of this method include that it allows for faster deliverables, granting increased visibility to stakeholders. With faster releases, users can provide feedback early and often, which can be fed back into the design team's processes. Handling unforeseen technical challenges is easier with this approach as well, as these hurdles can be solved with a redesign without having committed to a longer path. And finally, the biggest reason and advantage for this option is: budget. Between planning, estimating, and generating revenue, an agile design and development plan will boost all three of those categories. Requesting budget for smaller, discrete sections of an application becomes easier as estimates become more accurate, and quicker releases allow internal applications to make users more efficient, while external applications can begin pulling in sales.

The negatives for this approach are basically all of the pros listed for the other option: the UX team will not have incorporated the entirety of the application during the design process, and the development team will not have had a chance to architect based on a complete understanding of the workflows needed. Both applications (the soon-to-be replaced desktop and the web application) will need to be supported and maintained, with likely highly different codebases, languages, platforms, frameworks, requiring ramp-up time as they switch between the two.

Architecture Analysis

Regardless of the approach, one of your first steps will be to analyze your current application. Gauging how difficult this migration will be is dependent on how closely your developers, throughout the history of your application, stuck to software engineering best practices. If your presentation layer is purely the UI – just the elements your users directly interact with, with behaviors, business logic, data access, etc. split out cleanly into separate layers – then your path will be straightforward and iterative, with relatively low effort, and with an architecture that will not change.

However, most everyone knows this is not the case. Separating logic into the tiers it originally belonged to (or creating that tier in the first place), is what will dominate your effort. Database connections, business logic to determine values in a dropdown in the code-behind, dependencies on computation libraries and utility functions in the presentation layer – all of these are signs of highly coupled software, and will represent the bulk of your time spent during the migration.

A web client can't (and shouldn't) open a database connection to your data store. Business logic should be in its own layer, and if the rules change, you shouldn't have to sift through code that specifies button size and color to do so. This is the common state of desktop software and the biggest hurdle to overcome when migrating to any new technology. To create a plan for re-architecture, the basic premise is that all non-visual element code needs to move, either behind a service, into a utility, or available through a controller.

Hybridization

Our goal is not to rewrite the entire application, but just the parts that disobey the rules established by best practices. The end result should be a web page that displays (and possibly generates) visual elements, relying on a back-end server for the data to bind to its controls. Moving your middle-tier, or creating a proper one from scratch, and making it accessible via web services is one of the first steps in migrating your application, and will allow you to create a hybrid application with both desktop and web frontends.

If cloud distribution is something that was on your roadmap or list of things to investigate, this is the perfect opportunity. The choice of utilizing the cloud vs. an on-premises deployment boils down to how much control you want over the security of your application and data. Cloud servers can be used for the app, the data, or both, and can scale as needed. If security issues require that all data be hosted and controlled by your company, shifting just the application itself to a distributed model will still reap benefits for performance, depending on how data-driven your needs are.

Validation happens on both the client and server, depending on your domain. Simple validation (required fields, numerics, length, etc.) can occur on the client side, while validation against business rules should be handled via an asynchronous request to the server. If you didn't handle this in a separate collection of validators, then they will need to be moved out of your presentation layer.

Once the core application is properly separated behind controllers that respond to browser requests, you can modify the existing code within your desktop application to make use of them. This will allow you to make progress adding functionality to your web application without having to completely abandon your existing solution.

Frontend Form Factor & Design

With the backend and middle-tier properly architected, you'll need to make a decision on what form factors (desktop vs. tablet vs. phone) you want to address. Is this application meant only for desktop users? Are there workflows that could be made usable on a smaller device? Are there use cases that lend themselves to being more useful on a mobile platform?

Once you've made the choice, the design team can begin the work of creating wireframes for however many form factors you've selected, noting that tablet and phone should not always follow the same design or adhere to the same set of limitations. There's a reason I listed it as "desktop vs. tablet vs. phone" and not "desktop vs. mobile" – the distinctions can make a big difference, both in design and development effort.

Speaking of development effort, utilizing any one of the number of responsive frameworks out there is not (always) the solution to reducing it. Responsive design and the frameworks available are more geared to web SITE development, not web APPLICATION development. You may trim some of the time needed to create specific elements, but that time can then be spent to make sure the designs reflow properly across different resolutions, screen sizes, and density settings, resulting in a lot higher of a testing overhead than necessary.

Conclusion

We've walked through a general guideline on moving from desktop technology to the modern web, asking key questions along the way about why we should entertain this idea, what the possible benefits are, and what the most logical path forward might be. Development environments are extremely varied and present unique challenges, so the advice here is not presented as the only solution, but rather a guide that anyone can use to perform a sanity check before undergoing an expensive and lengthy conversion.