need help?

Build vs buy?

Follow Me

Keep Fixing vs. Rewrite: the Dilemma of When to Replace Your Custom Database Application

You worked closely with the designers to be sure your company’s custom database application would achieve your vision for your company.  You brought in your best employees to contribute ideas and learn the in’s and out’s of using the software.  You invested time, money, and resources, and you expected the solution to last for years – maybe forever.

But recently you’ve noticed that people are creating “stealth systems” – usually spreadsheets – to work around the Good Old System, and you ask WHY?

Everybody loves creative solutions - but do you really want to build your business on workarounds?

Does your system look a little dated but still meet all your business needs? 

Or does its shoddy appearance match its lack of functionality?

Is it time to retire that system you've been patching for years and build a reliable replacement?

Sometimes you need to replace a system instead of working around it
photo credit: bildungskatastrophe via photopin cc

Why Do People Create Workarounds?

One person says, “I need ‘what if’ analysis, and the Good Old System can’t do it.”

Another one says, “I have to take the information from the Good Old System and combine it with up to the minute data I pull from the web to answer your questions.”

Another one says, “I work from home at night, and I have to save my work in Excel and copy it into the Good Old System the next day.”

Uh, oh.  Now instead of giving you a competitive advantage, the Good Old System is hurting productivity by causing duplicate entry of information, and some of your key business data resides in spreadsheets and may never be part of your primary business application.

Is it time for a rewrite?  Or can your Good Old System be updated to address your current needs?

Keep or Rewrite?

If you answer YES to at least 5 of the following questions, you can probably update your existing system and avoid a rewrite.

  1. Do you have the complete source code for your system?
  2. Does your system collect the right information and present it to you in a way that meets at least 80% of your business needs?
  3. Does your system reliably and consistently save your data?  (You don’t have problems with losing data.)
  4. Is your system a web application or available through a VPN or other remote connection when you’re outside the office?
  5. Is your system fast enough to meet your business needs?
  6. Can your software connect to another application that might be used to consolidate information from your existing system with new data?
  7. Is the software used to write your system (e.g. Microsoft C# or Visual Basic; PHP; Java, etc.) still being supported?
  8. Does the information you use to make business decisions come primarily from your system?  (It doesn’t come out of spreadsheets or small, departmental systems.)
  9. Can you add new products, services, or other key information without calling a programmer?
  10. Do you get information out of your system in a timely manner?  (You don’t have to wait weeks to get your month or year end reports.)

If you answered NO or I Don’t Know to 5 or more questions, you may want to talk with your IT team or trusted software partner about where your current system fails to meet your business needs.

Worst Case Scenarios

In 25 years, we’ve been asked many times to maintain or enhance software written by others, and we have recommended a rewrite for only a handful of them.  Here are some of the worst cases.

  • The only programmer for the system died.  Two of our clients came to us when their only programmer for their primary business system died in the middle of an update.  There was no source control, no task list, and no indication about what was being changed.  There were multiple versions of the source code and the database, and no indication which version was correct.
  • The system periodically lost random data.  For months it would seem to work correctly, and then someone would notice that the system thought there were 5000 of an item in stock, when the actual inventory was 100.  Without historical transaction data, we had no way to determine why the system occasionally “lost” products.
  • There really wasn’t a system.  Management was making decisions based on disjointed information pulled from a group of disconnected small systems and large spreadsheets.  Each department entered its own information, creating many opportunities for data entry errors and causing reports and counts to vary from one department to another.  

Bottom Line

The decision on whether to create a new software application or to continue to maintain a legacy system is not an easy one.  It may feel like you’re abandoning something into which you’ve invested years of time and lots of money, but ultimately your decision has to be made based on facts, with a focus on your long term goals for your business.


DragonPoint frequently assumes responsibility for Microsoft .NET custom database applications written by others. We understand that software is an important business asset, and we work with you to get the most from your investment by stretching your system’s life and extending its capability by adding new functionality and enhancements.  Call 877-542-0657 for more information.