Working with Legacy Systems
Here at Software Planet Group, we often deal with all sorts of software projects. Some are brand new, while others are legacy systems. Recently, we received a request from a customer to work on a project that was created 13 years ago. This was a web-based game developed in 2009 with legacy technologies like Adobe Flash and the ASP.NET MVC Framework. The actual game mechanics were implemented as Flash content that was embedded in a simple webpage. In other words, the technology behind the project’s most essential module had long been dead and was classed as a lost cause.
Unfortunately, such hopelessness is a common thread for many legacy projects, and in this particular case, it hardly came as a surprise. After all, Adobe had kept Flash on life support for a number of years, despite the challenges to support its legacy codebase, which was already incomprehensible in places. The platform teemed with temporary solutions and changes imposed by impromptu security patches.
At some point, however, Adobe realised that the cost of supporting Flash would far outweigh any lingering benefits, so they finally made the rational decision to stop supporting Adobe Flash player for good. This was just as well. At the time, there were already a number of alternatives to Flash features, and due to the sheer amount of security issues that it was constantly introducing into their products, every major browser developer had also abandoned support for Flash.
The Customer’s Objective
The Challenges of Legacy Projects
When dealing with these types of migration projects, it is not uncommon to have to contend with no software documentation at all and have to reconstruct the ways to deploy the application, both locally and in public environments. This process may be compared to attempting to put together an ancient puzzle — but that is only part of the problem. The most challenging bit of the equation is making sure the outdated components will work. In this particular project, we had to jump through a number of hoops to make the outdated back-end functional again — as it had been written with .Net 4.5. In the end, we were able to obtain a working solution by migrating it to .NET 4.8 (2019).
How to Launch a Flash Application
Now, if you are wondering how to renovate a legacy system in these circumstances, traditionally, the way to get away from using Flash is to replace it with a newer technology. The game element, in such an event, could be re-developed using HTML5. But before examining this approach, we first needed to launch the application and find out exactly what our team was dealing with. On top of that, it all had to be done at minimal cost (as close to £0 as possible). So with this in mind, after familiarising ourselves with the codebase and the artefacts at our disposal, we identified three possible courses of action:
- use a Flash emulator — e.g. https://ruffle.rs — to run Flash-based components in a modern browser;
- install an older browser version which supports Adobe Flash player and can launch the application from there;
- use Flash Browser — a special browser with a built-in flash player.
Use a Flash Emulator
The emulator option, if successful, would provide far wider applicability, so we decided to make it our first attempt. Unfortunately, however, we soon found out that Ruffle was incapable of displaying third-party flv video files. At the time of writing this article, this unfortunately still remains the case. In practice, we were blocked by the following exception:
ruffle_web.js:1235 Error running definition tag: DefineVideoStream, got Invalid data: Invalid video codec.
There are also certain limitations on supported video file formats, so these must sometimes be converted prior to use. All of this essentially meant that this option was not suitable to this specific project. The approach itself, however, is still valid and should be considered in similar situations, as you might well be able to embed an flv into your swf files. It is important to also understand that Ruffle developers may eventually add support for external video files in future.
Use Older Browser Versions
Moving on, we also had to fix a number of compatibility code defects (both at the front- and back-end of the project). This would enable us to launch the game using older versions of Chrome and Firefox, where support for Flash Player was still existent. At last this yielded some positive results.
Use A Flash-playing Browser
However, because we were not entirely happy with the idea of using older browser versions, we decided to give the chromium-based Flash Browser a try. This is an open source product which significantly reduces security concerns.
Bingo. Not only was the game successfully launched here, but we finally had a working prototype which demonstrated the game’s UI, gameplay and mechanics. From this point on, we were able to plan the game’s entire redevelopment with a brand new tech stack.
Typical Challenges when Renovating Legacy Projects
Our developers were really lucky to have fla files on hand as well (animation project files created by the Adobe Animate program), in addition to swf ones. Otherwise, we would have had to do some serious reverse engineering by ”disassembling” the swf. This process does not often lead to the desired outcome and makes it nigh impossible to introduce changes to the flash code without breaking the app’s ability to launch.
In the absence of the fla files your swf files were built from, your chances of launching the project quickly become next to zero. Your best bet in such a scenario would be to attempt to rewrite the Flash functionality completely, by utilising an HTML5 canvas, for instance.
Another common concern is that the version of ActionScript used in the old fla files may also be severely outdated. In some cases, in order to introduce changes, developers have no choice but to rewrite the existing code with the latest ActionScript version, or re-develop the same functionality with the help of modern technologies.
System Migration: When Is the Time Right?
Many of the problems mentioned above may be mitigated or avoided entirely when a migration is counted on and planned accordingly. This is actually easily done, as the vendors of most libraries, tools and frameworks will seek to inform users regarding the end of life or deprecation of their software products well in advance. It is important not to leave migration tasks until the very last minute, however. After all, any problems encountered in production will already signal the urgency of the matter. On the other hand, if left unresolved, it may turn out that your solution can eventually no longer be migrated, and restoring it to working order will require a lot of time, effort and money.
With all of this in mind, if you are looking for a system or data migration software company, at SPG, we have over twenty years of experience handling many types of migration projects. We can assist you with the following migration needs:
- Upgrading an entire technology stack
- Replacing obsolete and unsupported solutions with available alternatives
- Discovering the feasibility of bringing to life your company’s dream products.
