A Java Developer's Guide to Migration

This article is featured in the new DZone Guide to Modern Java, Volume II. Get your free copy for more insightful articles, industry statistics, and more. 

Companies with desktop applications written in Java are under increased pressure to provide their users the freedom of a responsive web experience. Ideally, you could just run a desktop-style application inside a browser, and for a long time applets have made it possible to do just that. However, applets work using a protocol called NPAPI, which has been deprecated in most recent browsers. Today, the only real option to run a web application is to get pure HTML5 into the browser — not easy for most desktop developers given the new set of styling, scripting, and markup languages they have to learn.

There are many benefits of moving applications to the web, but some of the most challenging software projects have always been application migrations. What do successful migration projects look like? How do you eliminate a desktop system that has reliably run a part of the business for years, stay in budget with a migration, and delight users with a new browser application all at once?

Avoid These Common Pitfalls

#1: Overestimating Technical Skills

Overestimating technical skills can lead to both delays in producing code  and increased defects, since developers do a poorer job of predicting side-effects and remembering new conventions. Skills are one of the trickiest things to estimate correctly. The DevOps teams maintaining the current applications will be proficient in the current set of technologies, but often forget the years of effort that went into acquiring this proficiency. Coding conventions, naming conventions, namespace organization, software architecture, and testing approaches are just some of the choices that require more than casual experience to establish. However, most will be needed from the very start of any serious developments of the new software.

The problem is illustrated in the four stages of competence model: Unless the migration can happen in a way that leverages developer skills, transition for most will be from unconscious competence in the old to unconscious incompetence in the new. This black hole of unconsciousness is a terrible starting point for rational planning and realistic effort estimation of a complex technical exercise.

#2: Overreliance on Users for Requirements

Relying on users for specifications can result in surprises, especially towards the end of the project when acceptance starts, since many features are invisible to them. Users typically have many years of experience using the application but may not have comprehensive specifications on all features that exist, those that exist and work, those that work and are still used, and those that are used and used only in specific conditions.

Application migration initiatives often start with lacking or outdated documentation artifacts. For large applications it is also likely that there is no one single person in the organization who knows every feature of the application, but that many people have a small piece of the puzzle. In these cases, requirements can only be elicited through meetings and the occasional groupthink.

#3: Running Out of Steam

Frequent feedback and reinforcement from both users and developers breathe life into long-running projects.Modernization efforts are prone to being canceled midway. While the first version of the current information system might have gone into production in one go, business applications undergo all manner of corrective and adaptive maintenance as user needs evolve. Repeated in many theories of software evolution, enterprise applications change — but importantly also grow — over time. Compounded over multiple years, legacy applications can grow to include a large number of features that can make managing testing and acceptance activities a project in itself.

As long as the new system does not fulfill all of the feature requirements, users will see they have little choice but to continue using the system in production. Prolonged periods of not being able to deliver value to business are lethal to software projects, and many modernizations die this way.

Tips on Making the Migration a Success

#1: Do APM First

APM helps organizations focus their modernization efforts where they are needed most. Application Portfolio Management (APM) is a tool to help organizations identify which applications they are running and where the source code is, so it is a useful starting point for planning a migration anyway. But APM also goes further to help us analyze the value of the applications in our portfolios and allows us to plan modernization efforts strategically. With it we recognize that even if we select a framework as a strategic technical platform for the future, not all applications in our organization need to be rewritten to use this framework with equal urgency, if at all.

APM comes in various flavors, and one of the most widely known is Gartner’s TIME APM framework. APM frameworks typically categorize applications according to technical and business criteria, where an application can score either high or low on either. Applications that score high on business criteria (for instance, the application is an enabler of a key differentiator for the company) and low on technical criteria (for instance, high risk or cost of ownership) benefit the most from migration and should be prioritized.

#2: Find a Way to Reuse at Least Some Parts of the Existing Desktop Java

In migration, the shortest and most agile path is reuse. An easy way to convince a business that a new application is ready to be accepted is if the old and new applications, with identical data, can execute identical business processes to yield identical results. This is much easier when data structures and services of the production and modernized systems correspond or can at least be matched using a simple conversion.

Another reason why artifact reuse is worthwhile is that migration projects of large applications can easily take over a year to complete. In that time users will still expect new features to be implemented in the existing systems, and other updates may be required for regulatory compliance or to fix critical defects. In this dynamic setup, we want to make sure that things we change in the production system can be demonstrated to also work as intended in the new system. The more that production business logic, services, interfaces, and data structures can be leveraged in the new modernized version, the easier this synchronization becomes.

#3: Find an Incremental Approach That Works for Your Organization

Lower risk and the perception of risk by limiting scope. It’s likely that the business has a long list of wishes, and that developers have a far-reaching plan to deploy a future-proof IT architecture. When considering larger business applications, it is unlikely that an attempt to migrate big-bang style all code, while fulfilling all business wishes and all IT wishes, will succeed. Migration projects don’t happen for their own sake. For IT and the business to agree on an incremental modernization approach that will succeed, it is useful to understand which factors are actually relevant for driving the modernization and where the emphasis lies. Commonly there will be a combination of internal  rivers (newer, better-supported technology) and external ones (business agility and user freedom).

Following this exercise, there are different incremental approaches that could be considered:

• Modernize first the back-end, then the front-end.

• Fully modernize and replace one module or view at a time.

• Perform first a technical migration and then a modernization.

• Embed mini browser components inside the desktop application to make a gradual shift to web technology possible;

• Create an abstraction layer for the UI framework. This is often more expensive than doing a complete UI layer rewrite, but allows running and developing the legacy version during the migration phase.

Conclusion

Migration projects are daunting, especially when applications are large. Companies used to typical software maintenance scenarios are not used to scoping and executing these kinds of projects and many fail. APM, the appropriate reuse of existing code, and incremental approaches, improve the chances of success significantly. Getting help from software companies with experience in migrations is always a good idea if migrations are unprecedented for the organizations taking the step.

For more insights on Jigsaw, reactive microservices, and more get your free copy of the new DZone Guide to Modern Java, Volume II!