Automated migration is the process of using software tools--similar in concept and architecture to a compiler--to convert the original source code of an application to a more modern programming language, framework, platform, or all three.
Mobilize.Net's tools are all based on the same theories and architecture that allow compilers to work. Oversimplifying, there are three fundamental pieces in all our tools:
Mobilize.Net's tools are componentized (see above). This makes it feasible to modify the basic tools to perform new transformations. Both input and output languages/platforms can be modified. In addition, the architecture of the tools allow for substantial refactoring of application code, such as what happens when using WebMAP to migrate from Windows desktop to native web architecture using Angular and ASP.NET Core.
Automated migration using Mobilize.Net tools rely on iterative semantic analysis. First, all the application code, including external components, is parsed and typed. This symbolic representation is analyzed using AI algorithms to build a semantic representation of the intent of the code. Prior attempts by other computer scientists to do rich code analysis were limited to syntactic analysis; Mobilize pioneered true semantic analysis of source code over two decades ago. Mobilize stands alone in its ability to perform automated migration that truly replicates the intent of the code. The success of the approach has been proven by the billions of lines of real-world code that have been migrated with our tools.
Not every modernization project is suited for automation, but many are. Some of the characteristics of legacy applications that could benefit from automated migration include:
In cases where an application has many or all of these criteria, the organization is typically forced to choose between automated migration or a complete rewrite. See below for more information on the pros and cons of automated migration compared to manual coding.
Automated migration can, in a single process, convert 85-95 percent of the source code to the new target language and platform. The remaining work can be done by the in-house development team, and outside systems integrator, or Mobilize's own engineering services team. Actual project data, collected over a 15 year period, confirms that automated migration typically saves as much as 75 percent of the time required to rewrite a legacy application. Cost savings are similar, averaging about 20-35% of the cost of a manual rewrite.
One large government organization undertook to compare the actual cost of rewriting a legacy application with using Mobilize to migrate a similar application. Analyzing the actual data collected showed the cost of the rewrite was 3x compared to the cost of using automated migration. Additionally, the automated migration project was delivered as a fixed-price, fixed-schedule project, eliminating risk.
The history of software development is littered with the bleached bones of failed projects. Methodologies abound to avoid issues with development, yet they continue to be not only common but almost the rule. Even as recently as 2017 only 29 percent of projects were successful. Even organizations implementing Agile development only meet their schedule goal 65 percent of the time and their budget 67 percent of the time. While this is demonstrably better than 29 percent, are you willing to bet on only a 2 out of 3 chance of reasonable success? Furthermore, as the size and complexity of a project increases, the risk of failure can go up by as much as 10x.
And yet many companies undertake to rewrite aging legacy applications rather than investigate automated migration as an alternative approach. Here are a few actual examples:
This particular company had a VB6 application that was sold to vertical-market customers for years, leading to a strong market position. However, recent changes caused them to undertake a rewrite to create an HTML version (for, among other compelling reasons, to enable them to adopt a SaaS model). Over the course of almost two years, the company struggled to both keep the VB6 version up to date while building the HTML web version, constantly changing the new version's requirements to match the evolution of the VB6 version.
As is typical with these situations, the rewrite project included a number of ambitious goals:
If you guessed this set of goals was overly-optimistic, you'd be correct. Some of the problems they ran into included:
After over a year of struggle trying to get the project on track and keep it on track, they decided on a different approach.
Turning to Mobilize.Net, they were able to use automated migration to dramatically cut the time and cost of migrating their VB6 application to the web. Following verification that the migrated app was functionally and visually equivalent to the VB6 version--only now existing and deployed as a modern web application--they were able to quickly switch their licensing model from updates to subscription (SaaS), move their deployment to public cloud, and begin implementing DevOps and CI/CD.
Note that the automated migration did not move the needle on their goals to refactor the code into more modern patterns like full object orientation or DRY (don't repeat yourself). (Note: the automated process DID re-architect the code into MVC on the server and MVVM on the client.) But now the company had a modern code base--in production--which could be refactored and improved using modern tools, patterns, and affordable and findable developers right out of school. The team found that refactoring a lot of similar code into classes was more fun than missing dates and getting yelled at by management. Learn more>
Code quality in automated migration projects is a major concern, as well it should be. Some approaches rely on a runtime layer that effectively translates the source platform syntax and runtime library API into the target. This means the resulting code to be maintained looks almost exactly like the original application's source code. Why is that bad? Because legacy languages are not being taught in computer science curricula, nor are emerging developers either schooled in or interested in learning those languages. Additionally, if the migration relies on a runtime, there is now a permanent 3rd party dependency--do you want to bet your company on something you can't control?
There's no debate about whether legacy code needs refactoring. Older code rarely if ever shows modern patterns like true OOP, DRY, separation of concerns, loose coupling, and so on. Coding conventions, naming standards, and documentation/comments may be all over the map. Migration using automated migration tools can improve some of these areas, but not all. What automated migration CAN do is to get your app up and running on a new, modern code base using modern languages, platforms, frameworks, and tools so you can begin refactoring. Investing in refactoring AFTER migration makes far more economic sense than holding on to legacy code while refactoring BEFORE modernization. Modern languages and frameworks have built in support for constructs needed in your refactoring process--legacy languages and frameworks usually don't.
The process of syntactic translation of code from one language to another is relatively simple but does not represent a migration or modernization of the underlying application. To borrow from a famous movie, these are not the droids you are looking for.
Instead, anyone investigating tools to assist with legacy modernization should restrict their search to semantic transformation tools. Semantic transformation re-creates the application functionality in a new language with a new runtime environment. For example, converting VB.NET to C# is syntactic translation, while converting VB6 to .NET (with C#) is semantic transformation.
Mobilize.Net only provides tools capable of semantic transformation, not syntatic translation. Just as a compiler analyzes high level source code and creates low-level, optimized machine level code, both VBUC and WebMAP use static code analysis to understand the intent of the code, then generate a correct representation of that intent in the target language, framework, and runtime environment.
Let's review a few popular approaches to automated migration, including ours.
The workbench could be described as "tool assisted migration," in that it provides some assistance to help you migrate code file by file. With the workbench, you look at each line of code separately, evaluating proposed changes shown by the tool and selecting which ones you want to implement.
Pros: Since you are migrating each file individually, when you are done the project should compile and run right away. Many workbenches offer a direct way to extend the built-in mappings, sort of like using regular expressions.
Cons: Since each line of code is modified directly by a developer, this approach doesn't lend itself to spreading the migration across teams, each of whom might migrate similar code in a different fashion. This approach can create a tower of Babel in the final code, unless the teams are particularly effective at manually implementing a variety of standard approaches. Also: this approach is highly granular, since each file is processed individually. It prevents the migration process from working from a representation of the entire application.
Some approaches use a binary runtime that inserts itself between the source code and the OS. This approach lets the developer preserve a lot of the original syntactic flavor of the source language, while mapping virtually all of the behavior of the source libraries to the destination.
Pros: Migration is typically quick and easy. The resulting executable will run on the new platform with faithful mirroring of the original application.
Cons: Dependency on the vendor to maintain and support the runtime layer. If the runtime layer works, there are no problems. If the runtime layer has bugs or missing functionality, there is no workaround. If the vendor abandons the libraries (this has happened) or ceases business operations, there is no path forward. Further, this doesn't solve the problem of dependency on developers with legacy skills and knowledge, since it preserves most of the style and syntax of the source language. This approach also doesn't help companies who are struggling with compliance since the app will still require all of the old technologies (which are out of compliance - e.g. Windows XP, Visual Basic 6.0, etc.)
The Mobilize way. With this approach, the entire application is analyzed and understood before any code is created in the target platform, in order to ensure the best possible code quality.
Pros: This is the fastest and most efficient method to move the legacy code base to a new language, runtime environment, and framework. Iterative static analysis allows for understanding of the whole application before any code is generated. Output is native code using correct syntax and conventions of the target framework. Any and all helper classes are C# source code. Business logic is preserved without introduction of new defects. Functional equivalence is assured. Lends itself to team migration to reduce overall time required to deliver final code. The most proven approach, since more code has been migrated with this system than all others combined. You wind up with readable, maintainable code with no external dependencies.
Cons: The process requires real work, but it's orders of magnitude faster than rewriting.
