The tool everyone's afraid to touch
A lot of companies run on an internal tool built years ago — a Microsoft Access database, a Visual Basic app, an old PHP or on-prem system — that still works but is increasingly fragile. The person who built it may be gone, it only runs on one aging machine, and every year it gets harder to keep alive. But it also holds years of refined business logic, so nobody dares replace it.
That fear is reasonable, because the real value isn't the code — it's the accumulated rules. The rebuild has to preserve those rules while shedding the obsolete platform.
- Runs on unsupported or single-machine legacy platforms
- Original author is often gone; nobody fully understands it now
- Hard to change, hard to secure, hard to connect to modern tools
- Still encodes years of business logic you can't afford to lose
Preserving the business rules, not just the screens
The risk in any rebuild is quietly dropping a rule that mattered — an edge case in pricing, a validation that prevented a costly mistake, a report that finance relies on. We treat the old tool as documentation: we study its behavior, extract the rules that are still load-bearing, and confirm each one with the people who use it before rebuilding.
This is deliberate reverse-engineering, not a guess-and-hope rewrite. The old tool keeps running until the new one is proven to behave correctly.
- Reverse-engineer the existing tool to surface every embedded rule
- Confirm which rules still matter with the people who use them daily
- Migrate historical data so nothing from the old system is lost
- Rebuild on a current, supported, secure platform
- Validate the new tool against the old one before switching over
A safe cutover, not a risky big-bang
You shouldn't have to flip a switch and pray. Where it fits, we run the new tool alongside the old, compare outputs, and cut over in stages so the business keeps running throughout. The aim is a transition nobody outside the project even notices.
Once you're on modern footing, you also get the things the old tool couldn't offer — device access, real security and backups, and integrations with the rest of your stack.
- Run old and new in parallel to compare results
- Phased cutover instead of a single high-risk switch
- Keep the legacy tool available as a fallback during transition
- Modern access from any device, plus real security and backups
- Room to finally add the integrations the old tool couldn't
More on internal tools & dashboards
Frequently asked questions
We've lost the original developer — can you still rebuild it?
Yes; that's a common situation. We reconstruct the logic from how the tool behaves, its data, and interviews with the people who use it. The running system is itself the most reliable specification.
How do we avoid losing a critical rule buried in the old tool?
By treating extraction as its own careful phase, confirming rules with your team, and validating the new tool's output against the old one before cutover. The parallel-run step is specifically there to catch anything missed.
Can we keep using the old tool until the new one is ready?
Yes, and we recommend it. The legacy tool stays in service until the replacement is proven, so there's no gap in your operations and no forced leap of faith.