Software Rescue & Reengineering

Inherited a software problem?

We stabilise, document, fix and re-engineer applications that have become difficult to maintain, expensive to change, or dependent on a developer who is no longer around.

Most software rescue work starts the same way. The system runs the business. The person who built it has moved on. Every change takes longer than the last one, and somewhere along the line the roadmap stopped being about what the business wants and started being about what the codebase will tolerate.

That is a solvable problem, and it is rarely solved by starting again.

Signs you may need software rescue

• The original developer or agency has gone
• Nobody currently understands the whole codebase
• Every release seems to create a new bug somewhere else
• Performance is degrading as data grows
• Technical debt, not strategy, is setting the roadmap
• Frameworks and dependencies are years behind
• There are few automated tests, or none
• Deployment is manual, and only one person can do it
• Documentation is missing, stale or in someone's head
• Integrations break whenever a third party changes something
• Database queries have become the bottleneck
• Cloud costs keep climbing without a clear reason
• The architecture suited the original scale, not the current one
• An MVP has quietly become a production system
• There are parts of the system the team avoids touching

The answer is not always the same

Once we understand the system, the recommendation is one of these — and we will be specific about which, and why:

How an engagement runs

1. 1Technical discovery — What the system does, who depends on it, what hurts, and what the business needs it to do next.
2. 2Codebase assessment — Structure, quality, test coverage, dependency currency, known vulnerabilities and the areas where change is most expensive.
3. 3Architecture assessment — Data model, integrations, infrastructure, scaling behaviour and the constraints that actually bind.
4. 4Risk identification — Single points of failure, security exposure, unsupported components, missing backups, key-person dependencies.
5. 5Stabilisation — Stop the bleeding first — monitoring, logging, backups, the defects causing the most damage.
6. 6Refactoring or re-engineering — The agreed remediation, delivered incrementally, with the system live throughout.
7. 7Test automation — Coverage built around the areas you most need to change, so the next change is safe.
8. 8CI/CD improvement — Repeatable, reviewable deployment instead of a manual ritual.
9. 9Documentation — Architecture, environments, runbooks and decisions — written down so the next person is not starting where you did.
10. 10Roadmap — What to do next, what it is worth, and what can safely wait.

What re-engineering usually involves

• Monolith to modular. Extracting capabilities that need to scale or change independently — without a big-bang migration.
• Framework and language upgrades. Moving off end-of-life versions in controlled steps, with tests in place before each one.
• Dependency modernisation. Replacing abandoned packages and closing known vulnerabilities.
• Database redesign. Indexing, query and schema work where the data layer has become the constraint.
• API modernisation. Putting a documented, versioned interface in front of a system that grew without one.
• Performance work. Profiling first, then fixing what the profile actually shows.
• Automated testing. Starting where the risk and the change are, not chasing a coverage percentage.
• CI/CD and infrastructure. Reproducible environments, automated deployment, sensible rollback.
• Observability. Logging, metrics and alerting, so failures are noticed before customers report them.
• Cloud migration. Where it genuinely reduces cost or risk — not by default.
• Security. Authentication, authorisation, secret handling, dependency scanning and the obvious exposures.
• Documentation. So the knowledge stops living in one person's memory.

Working on systems we did not build

We are straightforward about the nature of this work. Code we did not write will contain decisions we cannot explain, behaviour that is undocumented, and occasionally things that only work by accident. We assess before we act, we tell you what we find including the uncomfortable parts, and we do not quote a full remediation before we have looked. An estimate given without reading the code is a guess with a number attached to it.

We maintain our own production system, not just other people's

We do not only build software for clients. Ausvanta is our own compliance and operations platform for Australian NDIS providers — rostering, GPS time tracking, incident management, claiming and audit evidence. We designed it, built it, and continue to operate it for paying customers in a regulated sector. That means releases, uptime, support load and production incidents are our problem too, not just a handover document. See Ausvanta.

Who we usually do this for

Australian organisations of roughly 20 to 500 staff running a system that matters: an internal platform, a customer portal, a SaaS product or an operational application. Often a founder-built MVP that succeeded, an agency build whose relationship ended, or a system that has quietly run for a decade. We also take selected larger engagements scoped to a specific application rather than an estate-wide programme.

Where this sits in our services

• Custom Software Development — the engineering capability doing the remediation
• Quality Assurance — the test automation that makes future change safe
• Cloud & DevOps — deployment, infrastructure and observability work
• Technology Consulting — if the decision needs a business case before engineering starts

Questions we get asked

Can another development team take over an existing application?

Yes, and it is a large part of what we do. It requires a structured handover rather than a cold start: we read the code, map the architecture and the data model, get it running in a controlled environment, document what we find, and identify the risks before changing anything. Where the original team is still available, even a few hours of their time is valuable. Where they are not, the code, the database and the running system are usually enough.

Should legacy software be rewritten or refactored?

Refactored, far more often than people expect. A rewrite restarts the clock on every bug that was already found and fixed, and business logic accumulated over years is rarely written down anywhere else. We recommend a rebuild when the platform is genuinely unsupportable, when the architecture cannot meet a requirement that actually matters, or when the cost of change has overtaken the cost of replacement — not because the code is unfashionable. The assessment comes before the recommendation.

What happens if the original developer has left?

It is a common starting point and it is workable. What we need is access: the source code, the repository history if it exists, the hosting and database, the domain and DNS, and any third-party accounts the system depends on. Missing source code is the serious case — if only a compiled or deployed version exists, options narrow considerably, and that is worth establishing early. We will tell you quickly if you are in that position.

How do you assess technical debt?

We look at what it is costing you, not at a score. How long a small change takes from request to production; how often a release causes a new defect; how much of the code is covered by tests; how current the frameworks and dependencies are, and whether any have known vulnerabilities; how the system performs under real load; whether deployment is repeatable; and which parts of the system the team is afraid to touch. That last one is usually the most informative answer in the room.

Can you modernise software without replacing everything?

Usually yes, and it is normally the better path. Common approaches include carving specific capabilities out of a monolith while it keeps running, upgrading frameworks and dependencies in controlled steps, putting an API in front of a system that never had one, redesigning the parts of the database that are actually causing problems, and introducing automated tests around the areas you most need to change. The system stays live throughout and value arrives incrementally.

How quickly can you tell us what is wrong?

An initial engineering triage typically takes one to two weeks, depending on the size of the system and how quickly we get access. You get a written assessment of the architecture, the risks, the security and dependency position, and a prioritised recommendation with options and rough effort — enough to make a funding decision.

Want a written assessment before committing to anything? Describe the system below, or request an engineering triage →