The developer left, the vendor folded, or the contractor stopped returning calls. What's left is a system the business runs on, with no documentation, no tests, and no safe way to change it. That system can still be brought back under control — but reading it comes before quoting it. The first deliverable is a written map of what you actually have.
Every one of these is recoverable. The order you tackle them in is the part that matters.
No handover, no documentation, and a system the business runs on. Everyone has quietly agreed not to touch it in case it stops working.
The code is there, but nothing anyone does produces a running copy. The only working version is the one already deployed, and nobody knows how it got there.
One box, one disk, and a backup nobody has ever restored from. The recovery plan is a phone call to somebody who left the company.
A one-line fix might break something unrelated, and there are no tests to say which. So the backlog grows and nothing ships.
An unsupported language version, a framework whose last release predates your newest hire, and security patches that stopped arriving years ago.
The shop folded, the contractor went quiet, or the price of a small change became absurd. You own the system on paper and cannot change it in practice.
Four stages, in order — each one is only safe because the one before it happened.
The first deliverable is a written map of your system, not a line of code.
Characterization tests that pin down behaviour nobody can explain any more.
Case study a two-slot deploy that refuses to stop the running version
End-of-life runtimes, known-CVE packages, expired certificates, secrets in the repo.
Case study a permission model that accreted one checkbox at a time, rebuilt as data
A named person who answers, an agreed response time, and a second pair of eyes.
Case study a platform that reports its own slow routes and busy threads
If the platform underneath it is genuinely dead — unsupported, unlicensable, or welded to hardware you can't replace — then the honest recommendation is a phased migration, and the documentation and tests we build become the specification it runs on. If the complaint is really about the process the software encodes rather than the software itself, point Lean Six Sigma at it before anyone changes a line.
Either way, the first deliverable is unchanged: a written map — what the system does, what it touches, what will break first, and what it would cost to fix each part. That document is yours whether the next step is us, your own team, or nobody at all for another two years. An assessment that ends right there is a legitimate result, not a failed sale.
Handing over a codebase is a real thing to ask. Scoped access, an NDA when you want one, and terms written down before we read a line.
Every quote starts from reading the system. The assessment comes first, and it's short, fixed-price, and yours to keep.
Support runs as a retainer on your terms, with documentation and access in your hands the whole way through. Further development works on the same terms.
When the verdict is replace rather than repair, that becomes a migration with a parallel run, planned one stage at a time.
Yes — that is the job. We start from what is actually running: the server, the database, the scheduled jobs, and the people who use it every day. Missing source makes it a harder start, not an impossible one; a running system tells you most of what it does. The first deliverable is a written map of what you have, and you keep that whether or not you hire us for anything after it.
Sometimes, and we will say so plainly. But rewriting a system nobody understands is how companies end up running two broken systems instead of one — the rewrite always misses the rules nobody wrote down. Documenting and testing first is cheaper, and it produces the specification the rewrite needed anyway. If replacement really is the answer, it becomes a phased migration with a parallel run, not a big-bang weekend.
Characterization tests. Rather than asserting what the code should do, we record what it does today — outputs, files, reports, resulting database state — and lock that in. Existing bugs get pinned along with everything else, deliberately, because the point is to detect change rather than to judge correctness. Once that net exists, an upgrade stops being a gamble and becomes a diff you can check.
Under an NDA whenever you want one, with access scoped to the people doing the work and revoked at the end. We work inside your repositories and your accounts wherever that is possible, take the least data that does the job, and test against masked or reduced copies when production data isn't necessary. Our confidentiality page states the whole arrangement in plain terms.
Right after a short assessment, yes. Reading the system first is what makes an on-call response time worth having: when something breaks, the engineer who answers already knows the code, the database, and the jobs around it, instead of meeting them for the first time during your outage. Once the assessment is done, on-call support runs on a retainer, with the response time agreed and written down.
The assessment is fixed-price and short, because it is the only part anyone can scope before reading the code. What it produces is a prioritized list with estimates: what is urgent, what is merely ugly, and what you can safely leave alone for years. You can stop there and hand that document to your own team — it is written to be used that way.
Point us at it. What comes back is a written assessment: what it does, what state it's genuinely in, and what making it safe to change would involve.
Call 832-598-8234 or email msco@stoneagesoftware.com. Houston, Texas — serving Houston, The Woodlands, Conroe, Sugar Land, Katy, Pearland, and the Greater Houston metro.
We read your message, an engineer replies with questions or a straight answer, and if a call would help, we book one. From the first reply on, you're talking to the people who'd do the work.
