In almost every business there is the one program everything hangs on. It was introduced long ago or built by someone in-house, it knows every special case, and nobody wants to touch it. The question “do we have to replace this?” usually comes not from dissatisfaction but from worry: what happens if it does not start one morning?

The answer is not always yes. Software ages differently from machines. A program that runs stably, is maintained and grows with the business can stay good for a very long time. This article helps you tell old from finished, and signs to watch from signs that call for action.

Old is not the same as finished

A system is old when its screens come from another era, when it uses terms the business has long since renamed, when staff operate it from habit and newcomers are puzzled. None of that is a reason to switch. As long as it does what the business needs, someone can maintain it and the data can be got out, old and stable is an advantage: it is well run in, and the costs are known.

A system is at its end when one of those three conditions fails - when nobody can maintain it any more, when it no longer does what the business needs, or when the data no longer comes out.

How to tell it is at its end

  • The developer is gone. Someone in-house or a small firm built the program, and that person has retired, moved on or can no longer be reached. The source code is somewhere, or nowhere.
  • It only runs on one machine. Usually the one in the corner of the office, on an old version of Windows that no longer receives updates, and nobody dares to restart it.
  • There are no more updates. The vendor has discontinued the product or only maintains the successor, to which the switch never happened.
  • Data only comes out with tricks. The export goes through a printout, through copying from the screen or through a spreadsheet someone fills with a macro.
  • New requirements fail. A new customer needs its own delivery notes, e-invoices have to be processed, a second site is added - and the system cannot do it, and nobody can teach it.
  • Staff work around it. Next to the system, spreadsheets, notes and mailboxes grow in which the real workflow takes place. The system is only fed so the invoice comes out.
  • Outages pile up. First rarely, then more and more often the workflow stops because the program hangs, the database is full or the printer no longer responds.
  • The knowledge sits with one person. Only the long-serving colleague knows which key triggers the month-end and why the field must not be left empty. When they are on holiday, the business waits.

One or two of these points occur in many businesses and can be fixed on their own. If four or more apply, the system is at its end, even if it still runs today.

What to do first

Before you look for a new system, secure what you have. Three steps that need no vendor:

  1. Take stock. What does the system do today? Which workflows depend on it, which documents come out of it, which other programs access it? Often nobody knows in full, because it has grown over time. Watching at the workplace shows it.
  2. Secure the data. Not just the backup that perhaps runs at night, but an export into a readable format: customers, items, orders, documents. Check that the export is complete and can be opened. If data only comes out with tricks, this is the most important step.
  3. Write the knowledge down. Sit down at the screen with the colleague who knows the system and write down what they do - every rule, every action, every exception. It is the basis for everything that follows, and it protects you against the day they are not there.

Two ways to replace a system

Once it is clear that the system is at its end, there are two routes.

Introduce a new system, with a cut-over date. All data is migrated, all staff switch on one day, the old system is shut down. This suits a small system with few users where a standard program covers the workflow.

Replace area by area. The area under the most pressure moves into the new system first, the old system keeps running for the rest, connected through an interface where possible. The other areas follow one by one until the old system has nothing left to do. This suits a large system with many special cases in a business that cannot afford a standstill. Cut-over date or step by step compares the two in detail; for Access databases the second route is almost always the better one.

We take the second route and build on ElbDesk, our custom ERP: sign-in, permissions, collaboration and documents come with ElbDesk, your workflows and special cases are added area by area. If you have an ERP, it stays - accounts and warehouse stay out of it. What happens to the data is covered in the article on moving old data.

Questions before you decide

  • Who can still change the system today - and who, if that person is unavailable?
  • Does all the data come out in a readable format?
  • Which recent requirement could the system not meet?
  • How much runs alongside the system today, in spreadsheets, on notes, in the mailbox?
  • What happens in the business if the system does not start tomorrow?

If you cannot answer the last question calmly, you have your answer. How a replacement without a cut-over date works is shown on our page on replacing old systems.