Why you shouldn’t modernise working ecommerce integrations just because they’re old
Old code isn’t automatically bad. How to make evidence-led technical debt decisions — and when stability beats architectural purity.
Old code isn’t automatically bad. How to make evidence-led technical debt decisions — and when stability beats architectural purity.
A broad service-layer migration of a catalogue integration would have added more risk than benefit. The legacy code was outdated but stable, so we documented and monitored it instead.
The rewrite trap
Rewrites feel productive but often reintroduce old bugs and new behaviour differences — especially in stock, pricing and order integrations.
RELATED GUIDEFlutter vs React Native in 2026: which should you choose? → Taking over an existing system?We adopt, document and maintain code other teams wrote.Get a free health check →When to change legacy code
- Security vulnerabilities
- Blocking a platform upgrade
- Measurable performance or cost problems
- Frequent incidents or change requests
When to leave it
If it works, is monitored and doesn’t block anything, document it and add tests instead.
Common mistakes to avoid
How we help with development
Frequently asked questions
Isn’t technical debt always bad?
Only when it has a cost. Unused debt with no impact can wait.
How do you decide?
We score risk, cost and benefit for each area.
Can you review our codebase?
Yes — see Software Consulting.