Buy or Build: When you reinvent, then reinvent again and again...

Most managers are concerned by the "Hit by a truck" syndrome.  That is, the original developer of a custom application can easily disappear, leaving them with no support and few alternatives. 

Alternatively, if your application was developed by an internal IT department, they may experience a rash of staff turnovers, or may be hit with significant budget cuts causing a turnover.

As a result, support on the custom application starts to crumble, with slower response times and longer times to resolve problems.  Plus, technology keeps changing, ultimately leading to the need for a major rewrite.

Persuasive consultants will argue that they will provide complete documentation, or that they will use a simple database package like Access. Ignoring for the moment that a truly efficient case management system would be difficult to reduce to a simple database project, you should not expect these steps will insulate you from a significant rewrite should another developer take over.

First, most any developer will admit there are very many ways of conceiving of and designing any software application even in Access.  Right and wrong may not be a factor...just different perspectives on the same problem play a key role in the choices made.

At any moment in time, if the original developer of the application is no longer available, a new developer is certain to find fault with at least some elements of the original design.  In part, this may be due to legitimate weaknesses.  In larger part, the common human tendency to look for a more efficient way can lead the new developer to suggest a significant rewrite.

However, the pace of today's technology makes a major rewrite even more likely.  Microsoft reports that computer technology changes ten-fold in just 18 months!  With this fast pace, and if an outside consultant or internal IT department has not continuously update the initial design, it is almost certain a new developer will insist on starting almost from scratch. 

Put simply, a design using the technology of 2 years ago is very likely to be much less efficient than today's technology.  Rather than spending time trying to understand the original, a new developer is likely to suggest it would be cheaper to start over and do it right with newer technology.

Of course, this is never the case with commercial software.  To remain competitive, an established vendor must maintain continuity in programming staff.  They also must continuously monitor changes in the technology and provide incremental updates to clients.  Without this monitoring and update system in place, they could not expect to last 6 months, let alone 20 years.