The legacy app nobody is maintaining is still holding customer data

Why the forgotten app is still a liability

Most mid-sized operations have at least one of these: a quoting tool, a customer booking system, or a staff portal built eight or ten years ago, hosted on a server someone forgot to decommission, still holding live customer records. The person who built it left the business years ago. Nobody on the current team has the credentials, the source code, or the confidence to touch it. It still works, mostly, so it stays running.

That's the problem. An application nobody maintains is still a system that collects, stores and sometimes processes personal information, which means it's still squarely inside the Privacy Act's reach. Australian Privacy Principle 11 requires an organisation to take reasonable steps to protect personal information for as long as it's held, and to destroy or de-identify it once it's no longer needed for any authorised purpose. A system nobody patches, backs up properly, or reviews for access control isn't meeting that standard, even if nobody's flagged it as a problem simply because nobody's looked closely enough to find one.

The pattern shows up repeatedly in system integration work: the legacy app is never the one anyone budgets to replace, because it isn't broken in a way that shows up on a dashboard. It just sits there, holding customer names, order histories, sometimes payment details, running on infrastructure nobody's patched since a now-departed IT contact left. Addressing it properly means secure system integration practices applied retrospectively, not just locking the front door.

Fixing it with custom software development

The fix is rarely a full rebuild from scratch. Custom software development, done properly, starts with an audit: what data does the system hold, who can access it, what business processes actually depend on it, and what would break if it disappeared tomorrow. That audit usually turns up more live dependencies than anyone expected, and fewer than the original vendor claimed.

From there, the practical path is staged replacement. New, compliance-ready software architecture gets built around the data the legacy system holds, with proper access logging, encryption and retention controls designed in from the start rather than bolted on later. Custom software development in this context means building exactly what the business needs to replace that one orphaned function, not buying a platform sized for problems the business doesn't have.

Finding every system still holding customer data

The audit step is where most businesses discover they have more orphaned systems than they thought. A spreadsheet tracking them is a start; a proper data map that traces every place personal information lands, including the systems IT inherited rather than built, is what actually closes the gap. This is the same discovery work that underpins custom enterprise software projects generally: before anyone writes a line of new code, the team needs to know exactly what data exists, where, and under whose control.

Government and open-data projects face a version of this same problem in reverse: publishing data cleanly requires knowing exactly what's being collected and validated before it goes out. The discipline in a project like government data integration work, where every record has to be traced to its source and validated automatically, is the same discipline a legacy data audit needs, just pointed inward instead of outward.

Replacing it in stages while the business keeps trading

Once the data is mapped, the orphaned application gets retired function by function rather than switched off in one move. This is staged system replacement in practice: new endpoints take over one workflow at a time, old data gets migrated and verified, and the legacy app's footprint shrinks until it can be switched off with nothing left depending on it. Businesses that try to replace an orphaned system in one cutover usually find out what it was actually doing only when something downstream stops working.

The timeline for this kind of work varies with how tangled the legacy system has become and how many downstream processes quietly depend on it, so any schedule offered before the audit is a guide rather than a commitment.