The complexity of legacy enterprise software systems are like earth’s ecosystem. Take away an entire species or add in lots of carbon and wholesale change starts to look pretty grim.
Legacy system modernization function much the same way. While stakeholder instinct is often to lobby for big changes when the subject of software modernization comes up, making due with what works not only makes transitioning to something different easier, it also makes updates simpler and more straightforward, too.
So how can you make software modernization run smoothly? Start by avoiding project killers – namely, keeping your biz and IT functions on good terms, making sure to avoid wholesale software ecosystem swaps, and finally, keeping your development and implementation teams small but mighty.
Common, costly mistakes can be avoided. Follow these guidelines and you’ll sidestep ecological disaster where most others have fallen off a cliff.
Don’t Underestimate The Incumbent
Thinking of enterprise software in ecological terms may seem a tad dramatic, but it’s not. Much like a functioning ecosystem, every part thrives through symbiosis. Software’s the same.
Consider your current software solution. It is the result of every feature and function you’ve needed in your evolution so far. It’s been iterated on thousands of times and probably holds information on your customers, business and processes that is more valuable than you realize.
Underestimate that ecosystem at your own peril. New isn’t always better. If a giant puzzle piece gets pulled, it could be a dangerous misstep costing much more than a couple dollars to fix.
Bigger Isn’t Better.
You wouldn’t drop a bomb on a big plot of plush farm land, right? Don’t do the same to your current enterprise software for a newer, bigger solution. Reality is, massive new solutions rarely meet expectations, no matter how well-conceived or intentioned.
When talk turns to “one foul swoop” solutions, step back and ask if a bigger solution will actually be better, or will it just be different? Your current system functions today. That’s a good thing and something you can bank on amidst many other day-to-day uncertainties.
Set Realistic Project Goals
Projects succeed with good parameters around it. Strong project management, too. Good constraints allow you to borrow the best of existing enterprise legacy software and implement new solutions for it to be modernized.
Avoid death-by-edit. Focus on building a healthy ecosystem by looking at your existing solution and taking the best lessons from it, seeking user guidance where appropriate on what works and what needs modernization. In short, get project teams excited for the update and who knows, real innovation might follow.
The point is to not stifle what’s possible and not to discount the valuable information sitting in your lap: what’s been collected over the years by your existing legacy system and the teams who rely on it. Properly applying that information can make modernization projects simple. In the process you’ll also avoid past mistakes, leveraging resources to ensure a bright future for your upgrade.
Transferring data after the fact
Business data is structured very specifically. Slotting it into a new database once it’s built is just asking for it. Systems require integration to function cohesively. New systems will often have their own structure for housing data. It’s own way of organization.
If a data dump is your plan on launch day +1, tread carefully. You’re heading into a conversion nightmare proceeded by apologetic stakeholder emails for systems downtime. We’ve seen this plan backfire many times. The outcome is often reversion to old systems because data integration for the new one was poorly planned.
Avoid this scenario by planning carefully. Data dumps should be done well in advance of launch day. Anything less won’t work.
Do we really need that?
Your enterprise software is so complex, so rich in features, that few people on your team are aware of everything it can do. While certain features might seem dated, redundant even, stripping them out could unknowingly impede your entire business.
Stakeholder engagement – or at minimum stakeholder representation – is critical for this reason. Once you start stripping out “unnecessary” features, your enterprise software functionally is impacted and launch might be too late to catch what’s missing. There’s nothing worse than having a slick systems upgrade people don’t want to use because of poor functionality. Or worse, people using legacy systems because the new one doesn’t work at all.
Inventory existing functionality
Project teams should always build a list of all existing capabilities. It might sound like a pain, but it exposes all the elements that are unique to your specific ecosystem. Functions that might be critical to biz operations.
Without a list, you’ll never have a clear idea of what’s important or what hasn’t been carried over in your systems upgrade. When functionality is missed, that’s when user groups get upset, labeling the new system as inferior to the old one.
When d(eployment)-day comes, you’ll know you’ve covered everything on your list. Your stakeholders will rejoice by dancing and holding hands. Well, at minimum by using the new system you’ve just poured so much energy into developing.
