Why and How to Bring Legacy Applications to the Web

We work with many clients bringing legacy (pre-web) applications into the modern era. This type of transformation carries with it a series of important concerns and planning requirements that can directly translate into project success.

As with any major business investment of time and money, the reasons for such a move should be justifiable with a series of questions:

  • Will this investment make my business more efficient?
  • Will this investment make my business more competitive?
  • Will this investment reduce future or recurring expenditures?

Although these questions may have seemingly straightforward answers, there are complexities involved in the details that are important to investigate as early in the project planning and scoping process as possible. “Legacy” applications may span a wide variety of user interaction paradigms that do not map neatly to the web.

Migrating from “Green Screen” VT3270 Form-Driven Applications

Migration of these types of applications are generally driven by high mainframe licensing and data center costs, or concerns around being able to maintain a talent pool knowledgeable in the skills required to maintain them.

These types of applications could be easily translated to the web by mapping the forms directly to a web browser. It has been posited that the browser offers little enhancement over VT3270 terminals. With an uninspired and uneducated equal-to-equal translation, some important potential gains can be overlooked or lost, and the project will likely not deliver on its success metrics.

Understanding the user’s needs in this type of application is essential. We worked with an education client where speed of data entry was something that they had with their existing green-screen app, and was deemed an essential requirement of the web-based application.

Knowing this requirement up front allowed us to tailor certain parts of the web user interface for high productivity; ensuring, for example, that particular screens were completely navigable with the keyboard, including the sophisticated AJAX-enabled custom controls.

Providing power users (who are generally big proponents of the existing system) a comfortable working environment in the new system will lead to their being your biggest advocates for change.

Migrating from Client-Server Applications

Migration of these types of applications is generally initiated by a desire to expose internal business practices or content to external partners or customers. Oftentimes, the business has a perfectly good internal business process and software infrastructure built around desktop-based applications and a central server. Problems arise when discussion begins around exposing this data or business process to the outside world, and generally degrades into disputes between the business stakeholders and IT about the best way to accomplish the goal.

These types of migrations usually end up following one of 2 approaches:

  • Add new web-based applications on top of a service-enabled enterprise architecture (possibly retaining mainframe systems as part of this architecture) which expose data or business process to the web. This is an evolutionary approach which reduces the business impact on existing internal systems.
  • Move the functionality of the client-server applications to the web, by reusing or rewriting the existing business applications on a more modern software stack. This is generally advisable if there are significant deficiencies in the existing software, similar to those discussed earlier regarding older mainframe applications.

Context-Setting Questions to Ask During the Migration Process

The process of migration should allow for time to revisit the business purpose behind the application. In addition to the aforementioned overarching questions about the investment itself, a thoroughly planned application migration should include the following types of questions to generate additional, incremental value over a simple port:

  • Has my business process changed since this application was coded 10 or 15 years ago?
  • What limitations of the current software are we working around on a regular basis? How could the new application be designed to refine the user interaction process to remove these limitations?
  • What are the business’s future growth and expansion plans? How could expansion points be factored into the new application to plan for inevitable corporate expansion or acquisition?
  • What types of functionality or data would be appropriate to expose to our partners or customers? What business value would this type of external exposure provide?

The Importance of Data Modeling and Business Reporting

A healthy, holistic approach to migration of legacy applications should start with the portion that arguably has the most value to the business, which is the underlying application data.

Reviewing the existing application data model can identify:

  • Legacy content or relationships that can be refreshed or discarded in the migration. This saves time and effort by not propagating data that is no longer relevant to the business, or has been subsumed by higher quality data. This often applies to “reference data” which may be obtained from other service-enabled systems in the business.
  • Content that has aged beyond a meaningful date. This data should be considered for archive and purge as part of the data migration process.
  • Business relationships that have evolved over time can be re-modeled based on the evolution of the business over time.

Tools and processes around data modeling have improved significantly in the past 10-15 years. Data models can be documented and transformed with little manual effort, and can change relatively painlessly as project planning progresses.

Additionally, existing enterprise-level reporting can be augmented with data from the new application. If enterprise-level metrics don’t yet exist, the context of the application migration process can provide a useful framework for focused EPM planning.

The Reality of the Awareness Gap

It is important to recognize that the stakeholders and technologists of a team responsible for a legacy application may not have the skills or awareness necessary to complete a successful transition to the modern web paradigm.

Effective application migration must incorporate functional and technical education of the web-based environment into which the business is moving. Bringing along all the stakeholders in the process of education and skills training is critical to ensure that the entire project team is aware of the possibilities provided by web-based applications, and begins to think in terms of the web and web-based content.

An effective way to foster an atmosphere of collaboration and open-mindedness is to work through a series of examples of user interface tools and techniques encountered on the modern web every day. Ask users to bring their own likes and dislikes to the workshop, or (even better) screen shots or web sites that they admire. A good moderator of this type of discussion will ask probing questions about what users like, and how they would apply these likes to enhance the application design.

Don’t be Afraid of Technology (or Technologists)

The early engagement of business-friendly technologists in the application planning lifecycle can be critical to the successful build and adoption of the finished web-based application. Technologists bring awareness of application platform features (and constraints) that business users are generally not aware of.

Discussions involving web application architects should focus on review and understanding of the overall application design and business architecture. This type of discussion will result in a web application architecture, which, like a traditional software systems architecture document, will provide a blueprint for high level consistency and delivery of the application and associated development practices.

Unlike a traditional software systems architect, the web application architect’s (citation needed) role is to ensure a series of additional concerns specific to web-based applications are met:

  • What is the business software systems environment? What browsers and platforms are in use? Green screen and client-server applications generally had the luxury of a single, consistent deployment platform. Lack of planning in this area could lead to decreased user adoption or frustration if their unique browser does not work.
  • Does the web application obey web content accessibility guidelines? Are concerns regarding Section 508 or WCAG accessibility important and addressed? Accessibility to all types of users requires special consideration during web application design, and can be extremely costly if introduced late in the development process.
  • Does the business have an international presence? Does the web-based application facilitate this? Limitations of legacy software platforms may have prevented expansion of the business into countries or cultures where complex alphabets or diacritics are required. Moving to the web implies exposure to a significantly larger and more diverse audience, with intricate language and usability considerations.

Business users alone are typically not equipped with the tools required to answer these questions and translate them to technical or software system requirements. Constant and meaningful dialog with high-level technical staff is key to avoid overlooking issues that are unique to web-based applications.

Iterative Development and Feedback

Many business users will feel more comfortable with a large-scale application migration if they are exposed to progress along the path to completion. This can be accomplished through software development lifecycle (SDLC) planning techniques, including a many-phased waterfall approach, or an agile, iterative approach. We have found that the proper approach is highly dependent on the project and the client, and often use a baseline SDLC which has been tailored to the client’s individual needs.

Showing users early and constant progress on the application can keep them informed of what is going on and allow them to have input at the formative stages of the project, helping them understand that it is “their” application.

Measuring Success

A successful legacy application migration to the web will be measured by the answers to a series of questions:

  • Does the web-based application improve business efficiency?
  • Does the web-based application resolve issues encountered with the legacy application?
  • Does the web-based application expose business functionality or data to an increased set of customers or clients?
  • Have all users made the leap to the web-based user interface? Empirical feedback from first-time users is critical to identify usability issues and functionality gaps.

While most business application migrations are successful, keeping the goals in mind (and ideally measurable) throughout the process is critical to project success. Success is not measured by a single aspect, but instead a completed recipe that combines ingredients of business, financial impact and planning, and forward-thinking technology.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s