Should you even think about application migration?

Even without an ambitious technical vision, organizations can benefit from an application migration if they can justify it through business continuity concerns or TCO reduction. This can be brought about by shifts in support for component technologies, developer tools, or runtimes.

How to get started with an application migration?

Smooth migrations take a lot of preparation. Two things organizations do to prepare are the Proof of Concept and the Migration Assessment. Do a Proof of Concept especially if you’ve done heavy customization of the existing developer libraries, or if you have strict requirements for non-functional criteria like performance, high availability, or scalability.

Migration Assessments help you plan your migration and make realistic budgets. Make a Migration Assessment if you want a full understanding of the dependencies of your application code, or if you’re stretched on manpower or time and are considering bringing in external help to give your migration a boost. Assessments can give you an expert second opinion in the complexities and risks of the work ahead of you and generate data to help planning.

What are the main drivers in a migration project?

Migrations are typically justified through a number of sudden or gradual pressures external to the organization. The sudden changes that make migration urgent typically have to do with support ending for components of the technology stack on which the application depends. If we want to keep our applications running, we’ll have to get migrations started to ensure they remain supported and continue to function. VB6, NPAPI, and Java WebStart are a few well-known examples where end of support forced many companies to migrate.

The gradual pressures that lead us to migrate have to do with gradual obsolescence that affects all technologies. As a technology stack gets older, it becomes more expensive to integrate the applications with other new platforms and it becomes harder to boldly innovate. It also becomes harder to find developers with the know-how and interest to keep working with these technologies.

What are the concerns when migrating very large applications?

Organizations typically wind up with large (>400 kloc) applications by leveraging a strong application architecture that was designed with growth in mind. Such architectures could be provided through specific developer tools like EGL or Oracle Forms; or enforced with developer conventions and application patterns like MVP or MVC.

As time passes and features accumulate, application modularity comes under pressure as developers attempt to innovate by integrating over module boundaries. As a result, these applications often contain a strong recurring application architecture but a heavy interdependency of modules.

This interconnectedness makes phased transformations harder to achieve, especially when the source and target of the migration are on different platforms. Whenever there is no tooling support available, big bang replatforming exercises that aim for feature parity can be an important enabler of subsequent modernization efforts.

Big bang or phased approach?

Many companies have migrated successfully to Vaadin following both big bang and phased approaches. Depending on the situation, both of these have the potential to be your migration’s enabler or its frustration.

Phased approaches have the benefit of enabling change and improvement at the same time as the migration is taking place. They tend to be more complicated though since they have higher technical requirements: some basic modularity of the application code and availability of a technical mechanism to allow the old and new sides to interact will be required.

On the other hand, especially if the application is towards the end of its lifecycle and there are infrequent releases of new versions, big bang becomes attractive for its simplicity. The benefits can be even more important when data must be migrated at the same time as the application code since you can avoid synchronization issues.

Big bang or phased isn’t an all-or-nothing proposition, however. A variation often seen is to first do a big bang migration that targets feature parity and has low user impact, followed by a phased modernization of the application with high user impact focused on the critical most-used views.

Before choosing a method, consider the skills you will need for the exercise and how long you will need them. Big bang migrations of large applications that have high user impact have much higher chances of sailing over budget due to unplanned extra requirements of stakeholders from different departments.

Why is Vaadin a good option for migration?

Vaadin is a versatile platform that can take on the shape of many interactive application architectures that seamlessly combine browser and backend. With Vaadin you get support for both distributed and centralized interactive application logic, both procedural and declarative compositions, and any object based architectural pattern your existing application might be based on.

With its full support for both server-side Java and client-side Web Components, the Vaadin platform can integrate seamlessly with a wide range of libraries or components your existing application or future plans may involve.

Why don’t organizations migrate sooner?

In most cases, it is because the existing applications work. The applications still support the organizations that run them and provide the required value, and for this reason they are tolerated. Users are rarely champions of larger application migrations since they rarely have a comprehensive view of the architecture and there are few consumer grade applications that support the full set of required functionality.

For smaller, less complex applications, replacement with commercial packages in the cloud or rewriting from scratch can be more attractive options.

What does Vaadin’s migration process look like?

When organizations outsource application migration work to Vaadin, the process we follow will be determined by whether the switchover will be phased or will go big bang. Phased migration approaches start with some form of embedding: Either a new Vaadin application that contains the old application embedded inside or new Vaadin views that get embedded within the existing. As the project progresses, the old application is replaced piece by piece by Vaadin. This approach follows a continuous integration process that may be familiar to most developers as a best practice. The downsides are overheads added to the regular releases of the existing application.

Big bang transformations introduce a clear separation between the existing application maintenance and the creation of a transformed product in a way that ensures agility of both work streams. Vaadin uses snapshot steering to keep the transformed product in synch with the existing application throughout the project. The benefit is application freeze periods can be minimized to just a few days. The downside is the users don’t get to see much of the new product until it is finished.

How realistic is it to reuse existing parts of your application?

When migrating Java applications (like JSP, JSF, Spring, or JavaFX) to Vaadin, many essential building blocks of your application become reusable. Floating point arithmetic, exception handling, accessibility modifiers, primitives, collections, streams, observer patterns, generics... all continue to function as intended thanks to Java’s backwards compatibility. And it gets better - by staying in Java, your UI and Unit tests may be reusable and can help you validate and accept the new application.

If you’re migrating an application from one language to another (like VB6 to Java), it’s certainly more challenging than moving from one Java platform to Vaadin. Java to Java transformations are more robust and a lot less like rocket science since there will be fewer errors caused by side effects relating to different VMs or language specifications.

What is application transformation in a migration project?

If your organization invested multiple man-years in the construction of your existing application, the application is an asset and has a certain value. There are many ways to migrate applications, and the value you see in your existing application will help you determine which ways make sense.

An application transformation leverages the value in the existing applications by focusing on its assets, like the source code. The effort it takes to complete will be determined by the scope of the changes and how deep an understanding of the code is required to perform them. If the impact of the technology change is reasonably low then your understanding might be limited to the syntax and the APIs. If the migration requires structural changes, impact and effort will rise.

Why would you transform your application?

Just as recycling is good for the environment, application transformation is good for your organization. If the existing application is large, integrated with many other systems, and valuable, finding ways to unlock value from it to build a new application makes good business sense.

Through transformation we reduce the impact of a migration on both users and developers, and we reduce the cost of the exercise. Both users and developers will benefit from being able to use the knowledge they have gained with the existing application and its architecture. It’s easier to keep our business happy if it can keep all the features it needs. And by reusing stuff that is tested and works, there’s less work and we can get more done with each iteration in our migration.