Before you rewrite the system nobody dares touch

Most established businesses have one. A system that runs something important, that nobody fully understands, written by somebody who left. It works. Everyone is slightly afraid of it. Every vendor who sees it recommends replacing it.

They recommend replacing it partly because a rewrite is a much larger invoice than a repair, and partly because reading somebody else's code is genuinely unpleasant work. Neither is a reason for you to pay for it.

What the old system knows that you do not

Software that has run a business for years has absorbed hundreds of corrections. The odd rule for one supplier. The rounding that had to change after an audit. The report somebody in accounts depends on every quarter that nobody has mentioned in eight years.

None of that is written down. It exists only in the code. A rewrite throws it all away and then rediscovers it one angry phone call at a time, usually during the first month end after go live.

The cheapest stage you can buy

Before deciding anything, pay somebody to read it and write down what it actually does. Not what the business believes it does, which is reliably different. That document is the most valuable thing in this situation, and it is useful whether you then repair, replace or leave it alone.

It frequently reveals that the real problem is narrower than it felt. The system is not failing. One report is wrong, or it will not run on a supported version of the language, or the only backup is on a machine under somebody's desk. Those are fixable without touching the parts that work.

When replacing is genuinely right

• It depends on a platform that no longer receives security updates, and cannot be moved.
• The business has changed so much that the model underneath is simply wrong now.
• Nobody can safely change it, and the cost of that paralysis is now larger than the cost of replacing it.

Notice that "it is old" and "it is ugly" are not on that list.

If you do replace it

Run both systems together for a period and compare their output on the same real data, rather than switching on a date and hoping. Migrate the data with a dry run first and prove the totals tie out before the real one. And when the balances do not agree, stop and find out why. A migration that was forced through to meet a date is a reconciliation problem that lasts for years.