How to prepare an application migration

There’s more than one way to peel a mango, and that holds true in particular for application migrations. Companies have been migrating applications for decades, yet no single “best” recipe has emerged that leads to guaranteed success in all situations. To get a successful result, you want to find the right answers to the right questions before you submit your budget proposal.

Plan your approach

In the ideal situation, in how many iterations would you like to free your application from its dependencies on old technology? The choice between one, few, and many breaks down as follows:

Transparency through continuous integration

In this extreme, the transformation would be indistinguishable from normal maintenance to the users and you would migrate legacy applications by changing them in-place, view by view or component by component. This kind of fine granularity is only possible with specifically designed compatibility frameworks like Vaadin’s MPR or custom-built solutions.



Modular Modernization

In most cases, however (for example migrating desktop applications to the cloud) the difference between the source and target platforms makes such transparently gradual transitions impossible. For applications with well-designed modularity, gradual migration may be possible but with coarser and clearer steps centered on the module level.


Big Bang Transformations

For larger, older enterprise applications, modularity is often weaker due to accumulated cross-module integrations, and it becomes harder to split chunks off to support gradual migrations. Big bang application transformations completely bypass the problem of modularization to enable fast migrations with full feature retention.


Proof of concept

Done right, a POC will reduce the technical risk of your project.



Make something that works

Migration POCs are smaller software developments that prove key technical aspects of a migration project. They can regard performance, integration, code reusability, or other key non-functional criteria. Doing a POC early will help improve the confidence in the estimates (and budgets) made for the full exercise during a migration assessment

Skip if not needed

POCs are optional. If the level of customization of the developer libraries in the existing application is low, and your organization has decided to follow a migration path that is supported by the vendor or by third parties, skip it. In that case, it makes more sense to profit from the knowledge outside your organization and collaborate with these experts to push your migration plans forward.

Discard after use

POCs are more valuable for the lessons an organization learns by doing them, than for the usefulness of the software they produce. If you’re thinking of creating a watered down version of an existing product and putting that into production, you’re not thinking of a POC but a pilot.

In general, the more your developers have written code to integrate with third-party software and the more that software has been customized, the more likely a POC will be advisable. It can make sense to involve external experts to help expedite answers, where the questions involve high uncertainty.

There’s no fixed size for a POC, but they typically last from 2 weeks to 2 months.

Learn more

Migration Assessments

While POCs focus on technical risk, Migration Assessments focus on impact. Once you’ve established how your transformation will take shape, it makes sense to identify the tasks needed and their effort so you can do realistic budgeting and planning.

To get the most of a migration assessment, it makes sense to work with experts who have done a similar migration in the past. Expect the experts to do an intensive, semi-automated 360-degree discovery and estimation of the migration from both a top-down and a bottom-up perspective.

In bottom-up, the experts you hire should use a set of software tools to parse the source code of your application and report the exact number of each type of dependency. For Java applications, expect sources and JARs to be needed in order to resolve all types referenced in the code. The experts should use this data to make a complete map of the libraries and APIs used.

Review objectives and constraints
Identify needed activities
Number of activities
Map of libraries and APIs used
Identify dependencies
Analyse source code

In top-down, the experts will review the objectives and constraints of the key application stakeholders. From this they can identify what activities are needed, the number of steps that are required, and how the different activities will fit together to enable a successful migration.

It’s possible your assessment also gets tasked to determine whether there is a viable business case for the migration project. If so, the top-down part of the assessment will probe much further to uncover the factors contributing to the TCO of the present application.

Based on these two halves of the discovery, your experts will make effort estimates for the required work and combine the findings into an assessment report. Armed with the data from the report and the expert insight, your organization will be able to plan and start your migration with more confidence.