There is a button on our imaginary distributor’s old system called Accounts Export 2. Nobody remembers what happened to Accounts Export 1. Every Friday, number two produces the file the accounting team needs.
It’s a small detail, but I’d keep it in view while discussing modernization. Old systems often contain years of working agreements disguised as slightly embarrassing interface choices.
A new planning year, following the .NET 8 release, is a reasonable time to review support and upgrade options. It is not evidence that every awkward screen needs replacing immediately.
We can improve the house while people live in it. We just need to remember that they still expect the taps to work on Tuesday.
Follow the export before replacing it
A review of that fictional button exposes several questions worth asking about a real legacy system.
Find the agreement behind the file
The export may depend on a particular column order, a filename or a cutoff time. Another application or person may rely on it in ways the current feature list doesn’t describe.
Ask the people doing the work what they check and what they repair afterward. Include their spreadsheets and manual steps. They are part of the operating process, even if the architecture diagram considers them socially awkward.
Capture what must remain correct, then distinguish it from what can improve. Recreating every historical inconvenience is not the goal. Accidentally breaking a useful dependency isn’t progress either.
A second opinion can save a lot of rework. Talk to us about consulting.
Identify what makes a change risky
Age is one clue, not a complete diagnosis. Stable, understood code may be less troublesome than a newer component nobody can restore after a failure.
Review runtime support, package compatibility, data ownership and the availability of a representative test environment. An application on .NET Framework may need a different migration plan from one already using recent .NET releases.
Technical debt also needs context. Martin Fowler’s discussion connects internal shortcomings with the extra effort they create during change.2 Prioritize the areas that repeatedly obstruct useful work, rather than promising to polish every dusty corner.
If the plan somehow turns into replacing everything while preserving every behavior exactly, Haibo! We should have another look at the scope.
Give one responsibility a new home
Fowler’s strangler fig approach describes gradually replacing capabilities while the existing system continues operating.1 Its appeal is delivering a bounded improvement that can be assessed before the next commitment.
For the distributor, a new reporting process might be a useful first phase. Compare its outputs with the existing process, agree who owns the data and establish how staff will use it.
Running two systems introduces its own work. If both can edit the same information, define which is authoritative and how updates move. Otherwise, a gradual migration can become two applications quietly disagreeing about the business.
Check out this blog: A heavily customized nopCommerce upgrade starts with an inventory.
Make the first phase useful on its own
A good first phase should leave the team better off even if the second is delayed. Removing duplicate entry or replacing an unreliable report can do that. Half a new application that nobody can use is a more difficult milestone to celebrate.
For the export, I’d want staff to rehearse a normal Friday and an awkward one. Check the numbers, missing data, recovery and the release plan. Agree what would cause you to reverse the change.
The business doesn’t need a heroic promise that the new system will solve everything. It needs smaller decisions supported by visible evidence.
Once the replacement has earned the work, retire the old process properly. Remove the dependency, update the instructions and tell the people who used it.
Accounts Export 2 can finally leave with dignity. We may never find out what happened to number one, and that’s probably all right.