Here’s how: Eat it one bite at a time Credit: Thinkstock Let’s face it: Digital transformation is hard, especially if your organization’s lifeblood rests on legacy systems. Here’s a proven way to get there. Pity the IRS? As soon as the new tax code was OK’d in late December, it had to start working over the holidays to update tax forms and withholding tables, for taxpayers to notice a difference in their pay stubs by—wait for it—February! It sounds relatively simple to change something like withholding tables—just plug some new numbers into the computer. But as former IRS Commissioner John Koskinen tells NPR, even simple changes are complex, thanks to Kennedy-era computer programs the agency uses. “A lot of our forms are hard-coded, so you don’t just enter a little thing in your computer, you actually have to go into the code and change the date or change the forms,” he says. No one particularly cares for the IRS, but you can sympathize. You know this. At least you are not alone. There are a lot of these systems out there. Great! Misery loves company but what are you going to do? The staff that knows the most about your legacy systems are retiring. Everything is hard-coded. Trying to make change is like pulling teeth. Hundreds of users only know the forms and processes embedded in those systems. And yet they keep clamoring for new functions and features and can’t understand why you can’t do it easily. And last—the cost of running the infrastructure just seems to get worse—finance is screaming! But there is hope. You have options. You can buy, build or try to migrate what you have. A lot of vendors will try to sell you on the first two options. Unfortunately, their motivations (to sell you something) may not always be in your best interest. You may think that the third is difficult, if not impossible but let’s look at a way to fairly evaluate all options. Set yourself some simple guiding principles and stick to them: 1. User acceptance Don’t kid yourself—lack of business focus kills most attempted transformations. That legacy code was written or customized to capture the processes and organization structure of the time. They are embedded in the code itself. Sure, over time some processes and structures have changed but remember the effort, expense and frustration of trying to make those changes? 2. Cost/risk mitigation Remember it’s not just the cost of new software, consultants and developers but user training. Consider the implications (cost and operational disruption) if the implementation stumbles? What kind of tests can you organize that will enable you to demonstrate that the new product works? 3. Understand what you really have Do not assume you or your staff really know. Unless you can safely state that everything is well documented you’ll be flying blind. That code is how old? There might be decades of twists and turns in there. 4. Eat the elephant one bite at a time When something is difficult approach it slowly and carefully. Break the challenge down into smaller chunks where you can exercise all the dynamics from beginning to end and prove that you arrive at the outcome you wanted. Got the principles down and everyone is on the same page? Good! Now you can go forward. The vendors promoting the build and buy options will probably conduct a lot of work for you as part of their attempt to advocate their solution, so let’s look at the third scenario: can you take you legacy system and move it to a modern platform where you can cut costs and more easily change functions and features. Conduct the assessment of the legacy. You don’t have to do the whole system. I suggest starting with a minimum logical chunk of the system that is enough to demonstrate performance improvements and yet representative of the whole system. Besides documentation, this will give you a benchmark to determine if the whole system is a candidate for transformation. Conduct an automatic conversion. There are several tools out there that can move legacy code onto a modern platform but still maintain those key business rules. This is an experiment. You’ll be able to determine costs, results, and risks. You should be able to extrapolate the lessons to a scenario where the whole system is converted. Now you have all the elements to argue a business case for buy or build or transform (assuming the vendors have done their job). You could probably encourage vendors to help fund the assessment. You may have had to spend some funds on the steps to conduct the conversion experiment but considering the magnitude of your legacy system’s impact, this will be money well spent. You can approach your three options anyway you like. Perhaps you would like to just do the experiment to see if your current legacy code could be transformed to a new platform? It’s up to you. You have choices. But let’s face it. You are going to have to cross this bridge soon. Maybe you have already put it off too long or gone down the wrong path. Make this year the time to investigate it and learn from other’s experiences. Software DevelopmentCareers