Almost every established business has a system everyone is nervous about: old, critical, and understood by one person. Replacing it feels risky, and leaving it feels worse. The good news is that there is a calm way to do it.
What "legacy" really means
Legacy does not mean old. It means a system that is hard to change, hard to support, or depends on knowledge only a few people hold. A ten-year-old tool that works and is easy to maintain is fine. A three-year-old one nobody dares touch is legacy.
Reasons to replace
- It is no longer supported, or runs on technology that is.
- It cannot be changed to meet new needs.
- Only one person understands it.
- It cannot connect to the other systems you now use.
- Security updates are not possible.
Reasons to wait
If it works, is secure and meets your needs, there may be no urgency. Replacing software for its own sake carries risk and cost. Write down what specifically is going wrong, and let that decide.
Big bang or gradual?
A big-bang switch moves everything over on one day. Simple to describe, high risk if anything goes wrong.
A gradual approach replaces the system piece by piece, with the old and new running side by side while parts move across. It takes longer but is far safer, because you can stop, learn and adjust at each step.
For anything important, gradual is usually the better choice.
Start with what the system actually does
Old systems accumulate hidden duties: a report someone relies on, an unofficial rule, a nightly task. Before replacing anything, map what it really does, by talking to the people who use it, not only by reading documentation. This is the same investigation described in our guide to a discovery phase.
Plan the data migration early
Moving the information is often the hardest part. Decide what to bring across, what to archive, and what to leave behind. Clean data first where you can. Test the migration with real data, more than once, before the final move.
Run in parallel
For critical systems, run old and new together for a period and compare results. It is extra work, and it is the best protection against nasty surprises.
Have a way back
Before the switch, agree what happens if it goes wrong. Can you revert? How quickly? A rollback plan that exists on paper but has never been tried is not a plan.
Do not forget the people
Even the best system fails if staff are not ready. Involve users early, train them properly, and make sure someone is on hand during the first weeks.
Do not rebuild everything
Resist the urge to recreate every old feature. Many exist for reasons that no longer apply. Keep what is valuable, drop what is not, and focus on the first release that delivers the most value. Related: fixed price or phased covers how to structure that work.
If you have a system you are nervous about, talk to us. Understanding it is usually the first step.