“It works. We don’t need to replace it.” I’ve heard this many times. It is usually followed with “It is slow. No one understands it 100%. We are fixing bugs every day. Delivering new features takes forever.”
There is no such thing as a future-proof system. Eventually, any application will become legacy.
Quantify if the cost of building a new system will be higher than supporting a legacy one is a pointless exercise. Even NASA’s Space Shuttle program from the ’70 was retired in 2010.
The question you should ask yourself is: when my application becomes outdated, what’s the plan for replacing it?
Start with the users. What do they find useful today? What’s painful? Write down the requirements as you were planning a completely different new application.
Hire a great architect. How do you know if an architect is great? Because she is eager to try a new way to design software. You want your system to last as much as it can, so you need to use the latest methods.
Put together a prototype team. You are not building a prototype to validate if the new approach will work. You are doing it because you need to learn the velocity, cost, and user adoption.
Users will be reluctant to use a new system. That’s why the prototype team should involve developers as well as users. Give them the task to implement one important feature.
Expand the team. After you ship a prototype, you can plan ahead. You can come up with a backlog, sprints, and milestones for the rest of the features. As you ship more features, invest in training users and creating processes (manuals) on how to use the new system.
Build a trust loop. You need to watch over the numbers, but trust is critical here. If the company is not buying your new system, you won’t be able to retire the old one, and keeping both functioning is a place you don’t want to be.
