The situation
BitSalt builds and sustains the software people depend on — this page is about the rescue side of that: business-critical applications nobody else will touch. (Got an idea for something new instead? That's a different page — see how we build.)
You've probably arrived here because something's wrong with an application your business depends on.
Maybe the original developer is gone and no one else will look at the code. Maybe the platform is past end-of-life and the vendor isn't patching it anymore. Maybe you need changes made and every quote you've gotten starts with "first we'll need to understand what this thing even does," and the estimates from there are terrifying.
That's the legacy modernization problem. And it used to be mostly unsolvable at small-business scale — the rewrite would cost more than the software was worth. That's changed. New development tooling has collapsed the cost of a structured rescue and made it viable for the first time to rebuild what was never worth rebuilding by hand.
What we offer
The rescue is a modular engagement, available in layers. You can take the whole stack or scope it to what you actually need.
Legacy application rescue
The core engagement: a parity-guaranteed rebuild onto a modern stack, delivered as code and documentation to your own repository. We survey the legacy application, define exactly what "parity" means for your situation, build an automated test harness against your real data, and migrate everything with a command your team runs themselves. The code delivers to your repo. Your team runs the migration, owns the deploy pipeline, and owns production. Our gate is code correctness.
This model is a genuine selling point, not a limitation: the engagement can deliver even while your production infrastructure, SSO rules, or deployment tooling are still being configured. Code correctness and infrastructure readiness are separate gates. We close ours, then hand off.
Deployment, cloud readiness & stewardship
Available as part of a rescue or a build, or as its own engagement: getting an application production-ready, deploying it, and then keeping it there. We don't consider "dependable" a true claim if the software ships onto a host nobody's watching — an unattended, unmonitored setup like that is exactly what turns into next decade's rescue. So if a system needs to move to the cloud, get production-ready, or just needs someone accountable for keeping it up, secure, and running, that's work we do — bundled with the build or entirely on its own.
We don't hand off responsibility for keeping it working. That's what makes "you can depend on it" true, instead of a slogan.
How we de-risk it
The guarantee is measurable, not asserted.
Before we write a line of code, we read the legacy application and document what it actually does — not what the spec says, not what the team remembers, but what the code does and what the database contains. We define the parity boundary explicitly: which behaviors the rebuild must match, which it may improve, which it must deliberately not reproduce.
Then we build the parity test harness — a suite of automated tests that runs against your real data, not synthetic fixtures. The threshold is zero mismatches on load-bearing fields. Not "close enough." Zero.
The migration command is one your team runs themselves. It refuses a populated target database without a typed confirmation token. It runs the entire migration in a single transaction — any failure rolls back to an untouched database. It includes a verify flag that re-runs the parity gates after the load, so you confirm before you go live.
The handover documentation is authored against the deployed application — not a spec, not what we thought we'd build. Your team should be able to understand, extend, and maintain the rebuilt system without us. That's the point of the documentation: not to describe what we did, but to hand you something you can actually use.
We have delivered this, with independent parity verification, on a real engagement. The data came across clean. Not as a claim — as a measurement.
See a case study — anonymized proof of the work →
What it is not
- Not a black-box hand-off The architecture decisions and handover documentation are part of the deliverable. Your team can understand, extend, and maintain the system without us in the loop.
- Not a guarantee nothing will change Legacy modernizations surface requirements the original specification missed. That's expected. The parity boundary makes the scope explicit; when something is discovered out of scope, it becomes a decision to make, not a surprise.
- Not a faster version of the old approach The harness, the data audit, and the parity boundary add rigor to the engagement. What they remove is the failure mode where the rebuild ships, the migration runs, and months later someone discovers that a column was silently truncated on thousands of rows.
What qualifies
We qualify on the situation, not the technology.
Any legacy stack is worth a look if the situation fits: the application is business-critical, the platform is past its support window, and the cost of staying stuck is high. PHP, COBOL, classic ASP, or something else — the stack is incidental. We're specialists in the problem of legacy software that has outlived its platform, not specialists in any one language.
The place to start is a conversation. Tell us what the software does, what's wrong with it, and what it would mean to have it working on a current platform. That conversation tells us whether what we do fits your situation.