Design Patterns for Legacy Migration and Digital Modernization

While designing the approach for any legacy migration, the following design patterns crafted by Martin Fowler can be very helpful.

• Strangler Pattern - http://www.martinfowler.com/bliki/StranglerApplication.html
• Event Interception Pattern - http://www.martinfowler.com/bliki/EventInterception.html
• Asset Capture Pattern - http://www.martinfowler.com/bliki/AssetCapture.html

Instead of a rip-n-replace approach to legacy modernization, the gist of the above patterns is to slowly build a new system around the edges of the old system. To do this, we leverage event driven architecture paradigms to capture inbound events to the old system and route these events to the new system. This is done incrementally till we can kill the old system. 

Having been in the architecture field for over a decade, I have realized that 'current state' and 'future state' architectures are just temporal states of reality!

It's impossible to predict the future; we can only be prepared for the future by designing our systems to be modular and highly flexible to change. Build an architecture that can evolve with time and be future-ready and not try to be future-proof. 

Another humble realization is that - the code we are writing today; is nothing but the legacy code of tomorrow :)
And in today's fast-paced world, systems become 'legacy' within a short period of time. Legacy need not just mean a 50-year-old mainframe program. Even a monolithic Java application can be considered legacy. Gartner now defines legacy as any system that is not sufficiently flexible to meet the changing demands of the business. 

Migrating applications across platforms

We often require to migrate applications from one platform (OS/hardware) to an other platform - either as part of a portfolio rationalization program or because the current platform is reaching its EOL. For e.g. migrating Java apps from Solaris/SPARC to Linux/IBM Power, etc.
During such migrations, it is essential to have a well documented plan covering all the aspects, so that we do not miss anything. Listed below is a brief set of points that must be included in the brainstorming discussions during the planning phase.

1. Migration of the Runtime environment: For e.g. miration of the Java runtime from Solaris to Linux. There are many JRE's available on Linux and we need to select the appropriate one.
2. Migration of the Application Infrastructure: The application may require a webserver, application server, a Message queue, etc. These infrastructure components would need to be ported to the target platform or other alternatives selected.
3. Migration of application code: Does the code need to be recompiled/linked on the target platform? Was the application using any platform specific API for performance?
4. Migration of application configuration: What configuration needs to change on the target platform? e.g. file paths, endian-ness, max-memory settings, thread pool settings, etc.
5. Migration of development environment: Would it be required to migrate the development environment? Will the same IDE work? IDE-Runtime integration issues, etc.
6. Migration of Build and Deployment process: Need to change build scripts - ANT, Maven, Shell scripts, etc.

Also it makes sense to leverage the expertise of the target platform vendor during the migration exercise. For e.g. IBM, HP, SUN, RedHat, Novell, etc. all have guidelines, recommendations and migration kits for migrating from a target platform to their platform.

Java to .NET conversion tools

Today one of our teams was looking for a Java to .NET conversion tool. They had developed resuable components in Java and the client wanted similar components in their .NET environment.

Microsoft used to ship a module called JLCA (Java Language Conversion Assistant) that enables us to covert Java code to .NET code. This tool was shipped as part of VS 2005, but unfortunately is no longer shipped with VS 2008. Please read Microsoft's statement here regarding JLCA. 

I had a quick look at the tool by launching it from VS 2005 and selecting a few Java util libraries. The results looked good, but we need to understand that 100% conversion is not possible. The tool puts in a lot of comments in the generated .NET code, so all errors and warning are maked in the generated code. Also a cool HTML report is generated that mentions the errors and warnings. I could find tons of errros/warnings, but most of them fell into expected categories such as no direct mapping between Java and .Net classses, etc.

ArtinSoft offers an enhanced version of the JLCA tool called JLCA Companion. I have not evaluated this, but the documentations states interesting features for customization.

To summarize, I believe such migration tools are useful to jumpstart the process and have a foundation ready to work on.