Migrating Legacy Apps: 7 aspects to consider
Updating or modernizing key legacy applications has become a high priority for companies all over the world as they pursue digital transformation. Often driven by tech infrastructure and operational needs. This blog highlights 7 aspects to thoughtfully consider before migrating your existing applications.
Legacy migrations are initiated for a couple of reasons. The existing legacy system could be anything from a completely undocumented application on a system where spare parts come from eBay written in a language originally developed by a developer that had his retirement party in the same year that you graduated kindergarten to that state of the art SaaS solution that was implemented last year when the business was different and isn’t what the business needs now. Whatever the technology, it’s something your business inherited from an earlier process or company lifecycle and it’s not the system that you need right now.
In his column for Forbes (2018), Technology Analyst Dan Woods makes a valid point: “A legacy app migration project that just moves an app from one platform to another can be beneficial, but is far from the biggest win”. Time to take a closer look at legacy application conversion. These are 7 aspects to thoughtfully consider before initiating legacy migrations:
1. Legacy reason
Why is this application legacy? It is just something you don’t like and would prefer to replace, or does it have such a (potential) impact on the business that you need to act now or risk the continuity of your business. How did you end up in this situation and is there anything you can do to correct the situation without replacing the application? How do you make sure that any changes you decide on now don’t result in the same challenges a few short years down the road?
2. Access to data
Can you access the data of your legacy application to replace it and do you need to? Does the current solution provide an API or other data access that will make converting to a new solution less complex, do you even need this data, maybe it’s better to start over?
3. Business logic
Where is the business logic for the application? In the situation of a standard off the shelf application this is probably hidden, in the case of custom software this is likely in the documentation if it exists and then it’s probably aged and not sufficiently updated. Do you still have access to the original application, and is there someone who can read and understand the original source code?
4. User interface
If you’re in the situation where you want to replace a system where you have access to the data and understanding of the business logic it may make sense to start by replacing the user interface. This often happens in situations with extensive custom software on an aging platform, for example only accessible using special terminals or emulators. Redesigning parts the user-interface while initially leaving the data and business logic on the original platform and slowly migrating those to a more modern platform over time might make the transition faster, less impactful and lower risk.
When do you have (this is different to want) to complete the legacy system migration? This can be driven by technical needs (end of life of technology), personnel (developer leaving) or business driver (cost of solution, changing of process) the answer to this question could impact your cost and decision-making flexibility to a large extend.
6. Standard or custom
If there is standard software available that you can make work for your situation, ALWAYS go for standard software, over time the cost of standard software is always less than custom solutions. If you decide that the standard software can work with some minor adjustments, really really really consider what you are doing, standard software with even minor adjustments is not standard anymore! Standard software augmented with add-ons using defined API’s however could be a valid solution.
7. Like-for-like or update
Depending on your reason to replace that legacy system you may have a choice to either create a new application that has the same functionality as your current solution or you may want or need to make changes to the functionality of that application. In case of a like-for-like you’ll almost always get stuck selecting a custom solution for your replacement, it is not likely that a standard SaaS or of the shelf application is identical to your existing one. When you update, do you change your process to match the application or your application to match the process? It may be advisable to first migrate the application to new technology before you start changing, having a solid understanding of the interaction between the data and business logic is a key requirement before starting to make changes.
There are (possibly many) more aspects that arise during the process of deciding when and how to migrate your legacy applications. This article has hopefully given you some pointers to make a well-considered decision in this area.
“No code platforms make development into a process of configuration, eliminating coding and making testing and deployment even easier than low code platforms,” according to Woods. No code platform WEM helps businesses to migrate their legacy applications either as a standard for custom application or to enhance a standard SaaS or of the shelf application with those few processes that are specific to your business situation.
Read our previous blogs:
4 WEM features to simply model complex applications
WEM Conference 2018: Inform, Inspire & Connect
Shadow IT: How to deal with this in your organization?