Backend bogging you down? Modernize your software

Before getting into the technicalities of legacy system modernization strategies, it’s important to define what you’re asking for. While these definitions may vary slightly depending on who you ask, this is how our teams at Praxent use the lingo, and this usage tends to be pretty consistent among industry experts.

Legacy Software Modernization: A retooling plan for the front end of a legacy software that provides improvements or enhancements of the current capabilities of the system. The “back end” of the system, or where the data is stored, doesn’t need a complete re-architecture (though it may be redesigned or upgraded within its current structure).

Legacy Software Migration: the process of moving or reconfiguring data repositories, architecture, and other existing back end systems from one platform to another. In migration, the user functionality and “front end” of the system does not change or changes minimally, and changes are only made in the way that the system works and/or data is stored in the background.

The key distinction here is that migration only needs to occur as part of a legacy software modernization strategy if relocating the system is absolutely necessary to achieve the modernized functionality.

Think you need to migrate your legacy software? Stop and read this first.

Software migrations can, frankly, be a nightmare. Pardon the grim analogy, but if you ever needed major surgery for say, a leg injury, chances are you would search out the least invasive, quickest-healing procedure so that you could get back on your feet and get on with your life as soon as possible. You wouldn’t choose to perform an unnecessary amputation and seek out a prosthetics engineer to build you a new leg, and then expect it to work better than the original.

Given that the complexity and intricacy of most enterprise systems are comparable to the inner workings of a human body, that same common sense approach of minimal invasiveness should be applied to any legacy modernization approach. Nonetheless, stakeholders often tend to choose the software equivalent of amputation and prosthesis rather than working with the good parts of the existing software to make the whole thing better and the transition smoother. In other words, employing a legacy system modernization strategy.

The overly-complicated and often catastrophic software migration process is usually the result of three common yet devastating myths:

Myth #1: Your current business model should not constrain your software migration plan.

Myth #2: You can build and launch an entire new version of enterprise software in one fell swoop and expect a smooth and swift transition.

Myth #3: A small team of higher-level stakeholders and developers can successfully create and implement this migrated software without the involvement of your larger stakeholder group, such as general users of the software.

In many scenarios, the software migration process is much higher risk and higher involvement than simply modernizing the look and feel of the system while reorganizing some of the functionality. In other words, you don’t always need a new leg – you just need to see a physical therapist.

Underestimating the incomprehensible amount of information that your current system is built upon is the fundamental mistake that often sets off a cascade of other mistakes, ultimately killing your entire software modernization strategy.

Be prepared for the project to be larger and more complex than you first anticipate. Make sure you assign experts to the project who have intimate knowledge of the legacy system, and keep your stakeholders engaged by delivering iterative business value as much as you can.

There’s no getting around it – legacy software modernizations and migrations are big processes, and achieving success is a journey, not a destination. Attempting “big bang” deployment, i.e. expecting to move from your current software to an entirely new system in one fell swoop on a dedicated “go live” date, is unrealistic and dangerous. It all goes back to that grave underestimation of what it took to get your current system functioning as it does today.

There are almost always tasks that can’t be automated and blockers that couldn’t have been anticipated in the first phase of the project. Additional manual effort is usually needed to keep your business moving through the initial stages of the project. Be prepared for this difficulty of the first phase, and realize that it may make you or your stakeholders feel like it’s not worth it.

Keeping all invested parties engaged and excited is crucial. While painful at first, a well-executed software modernization strategy provides invaluable long-term benefits, including the ability to scale and identify new revenue opportunities. When things get hard, remind yourself and your team that the legacy software is costing you money every time you have to scale operations. A modernized software system will allow you to stop focusing on maintaining your infrastructure, and start focusing on business strategy and new growth.

The right project constraints and guidelines can set you up for success, but there are some misguided ones that often emerge from the myths mentioned earlier. These constraints can actually inhibit the best solutions to your current software problems.

Placing constraints on your development team against things like rework, looking to the existing system for guidance, or access to the project before completion, can be very counterproductive to your overall goals. These limits can stifle innovation and prevent problems from being caught early on. They can also prevent the ability to put to work the plethora of valuable information that was collected over the years of using your legacy system. Accessing and properly applying that information can prevent a repeat of the same mistakes that made you want to modernize your software in the first place.

Moreover, by approaching a legacy modernization project with too static a mindset, you will lose the ability to be prepared for often-inevitable additional labor costs needed to keep your project on track in a positive direction. While sticking to an overarching budget should be of the utmost priority to you as well as your software development firm, an inability to move investment around to shifting priorities will cripple both your current and future systems. Set yourself up for maximum project ROI by preparing for change now, so that your software can get off the ground later.

Even if you’ve chosen a legacy modernization approach rather than a full data migration, you will still have to orchestrate some data transfers. Attempting to migrate all the business data from your legacy system into a new one only after it has been built is the equivalent of trying to build a ship in a bottle by constructing the ship outside of the bottle and then trying to squeeze it through the impossibly small opening. Your existing business information is structured in a very particular way within your current database.

If you try dumping all of that information into a new system that structures data in a different way, you’ll end up with a huge data conversion mess that could potentially lead to a failure to launch your new software, a total destruction of your budget, and could even force you to revert back to your old system.

Instead of scrambling to reactively fix flawed data, take a close look at the data relationships and information hierarchies that hold together your legacy system, keeping in mind that companies using legacy software are often living with workarounds. Sometimes, the necessary software modernization strategy will require your company to redefine the data relationships and information hierarchies of your legacy system. This move will drastically change the resulting user experience, reporting requirements, and back-end system integrations, so don’t save it for the end of your project. Discover and address structural problems and brush up on software migration best practices before you begin designing your new system.

Enterprise software is typically so loaded with features and functions that it’s highly unlikely any one individual stakeholder is even aware of every single capability that exists in your system, let alone utilizes all of it. While one particular feature may be completely irrelevant to one department or subgroup of your stakeholders, it may unknowingly be crucial to another group.

Given the complexity and variety of features within your enterprise software, it can be highly detrimental to exclude any functionality in the modernized version. Some features may seem outdated or insignificant, but their absence in your new system could potentially derail the flow of your entire business process.

It’s very common for several of these features to be recognized only after a new system is implemented, leaving businesses stuck with a fancy new piece of software that no one wants to use because it doesn’t do everything their legacy system can.

Actively creating an inventory of all existing capabilities and usages in your current software may sound cumbersome, but it’s a lifesaver. Consider the fact that many functions of your current system are “behind the scenes” triggers. These triggers are likely significant, if not crucial, to your business practices; yet, without a list, these and many others will likely be forgotten as your team works on plans for the migration or modernization of the system.

As mentioned earlier, excluding any existing functionality from the updated software, whether intentional or accidental, could be a deal-breaker for your stakeholders. We’ve seen it time and again: user response in these situations is to label the new system as unreliable and cling to the old and familiar, knowing it has everything they need.

Legacy systems also often contain hidden user workarounds that become tribal knowledge. These workarounds become so routine, they can be completely missed when gathering requirements for the new system. When they are identified later on in design or development, you’ll have to allot additional time and budget to work them into the new system.

This list of pitfalls and roadblocks may feel entirely overwhelming. How in the world do ANY legacy modernization projects go successfully?

With the right development process, not only is it possible to resolve all of the issues with your current system, to implement the new features you’ve been wanting, and to make the system run the way you always wished it had, but you can reach those goals much more quickly and at a fraction of the cost of a new custom build. Too many firms choose the wrong development approach, leading to chaos down the road.

Successful legacy system modernization projects leverage the Agile approach to updating your current software piece by piece, early and often. This is a method that has enormous advantages over a complete rewrite:

• You get early exposure to the solutions that have already been developed
• Catch problems early on and resolve them as they come up in the development process.
• Have usable chunks of your project implemented within weeks — not months or years.

In a world of custom enterprise software development where there are few silver bullets, this method truly stands out in its ability to bring software success to your stakeholders. If your IT person tells you that starting from scratch with a new system is the only way, that a Waterfall development process is the best choice, or that a full legacy migration strategy is an absolute must, it may be wise to do some investigating of that claim and get an outside team of developers to assess the situation.