The easiest and fastest way from Swing desktop to web
Swing to Vaadin
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 one 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.
How you will update new and old versions of your application at the same time will be key for your approach.
Test non-functional aspects of your migration to prove technical feasibility or understand the effort involved.
Learn More
Identify your application’s dependencies, measure effort, and see which options still fit your constraints.
Learn MoreIn 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:
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.
In most cases however (for example migrating desktop applications to 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.
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.
Done right, a POC will reduce the technical risk of your project.
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
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.
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.
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.
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.
From developer to decision-maker, get the insight needed to budget and start your migration in confidence. Vaadin uses a proprietary toolkit to identify each and every dependency of your sources on the frameworks you are replacing. Vaadin experts analyze the dependencies and create optimal mappings and effort estimations. Full data and analysis are shared with your team.
A POC is a small software development exercise that examines some essential technical aspect of your migration. It can deal with performance, integration, reusability of the existing code, maintainability or other key questions. If you’ve heavily customized your existing developer tools, doing a POC will help you reduce uncertainty in your budgets.
