When a vendor announces the end of support, nothing changes day to day at first. Orders are entered, invoices printed, the warehouse books. That is what makes the news treacherous: there is no day on which you have to act, so often nobody acts at all. Until a new regulation arrives, an operating system update breaks something or a fault can no longer be fixed.

This guide describes what the end of support actually means, what you should do first and which routes there are afterwards.

What the end of support means

The word “support” covers several things, and all of them go away:

  • Security updates. Holes in the software are no longer closed. For a system holding customer, supplier and bank data, that is not a theoretical risk.
  • Changes for new regulations. When formats or obligations change, for example with e-invoicing, the vendor no longer ships a new version. The system then cannot do something the business has to do.
  • Compatibility with its surroundings. New versions of the operating system, database or Office are no longer tested. At some point the program no longer starts after an update, or the export fails.
  • Help with faults. When work comes to a halt, there is nobody left to call - or only on terms the vendor sets itself.

None of this happens on the end date. It happens some time later, and usually at an awkward moment.

The first three steps

Before you ask for quotes, build a foundation. You do not need a vendor for it.

  1. Clarify what exactly is ending. Is it only this version, with a successor available? Is the product ending altogether? Does the vendor offer a migration, and what does it carry over - only the data, or your customisations too? The answers are rarely in the letter, so ask.
  2. Record what the system does today. Which workflows depend on it, which documents come out of it, which other programs access it, which special routes were built in over time? Usually nobody knows all of it. Watching at the workplace shows it.
  3. Back up the data in a readable format. Customers, items, open orders, documents. Check that the export is complete and opens. What happens to the data during the switch is described in the guide on moving old data to a new system.

With these three points you know what you are parting with - and what must not be lost under any circumstances.

Three routes after the end of support

Move to the successor version. It sounds like the smallest step, but it is often a new introduction: a new interface, a new data structure, and the customisations of the old version do not come along automatically. This fits if the old system was hardly customised and the successor covers your workflows.

Introduce a different standard ERP. This makes sense if your workflows largely follow the standard of your industry. The switch usually happens on a cut-over date, with all areas at once. What speaks for and against it is in the guide Cut-over date or step by step.

Replace area by area. The area under most pressure moves into the new system first, the old one keeps running for the rest, connected through an interface where possible. This fits if the system knows many workflows of your own and the business cannot afford a standstill. This is the route we take, on ElbDesk, the foundation we build on.

What speaks for which route

  • How closely is the old system adapted to your business? The more special routes, the less a standard system brings out of the box.
  • Who still knows the customisations? If it is only one person, writing them down comes before any decision.
  • Which area is under most pressure - and could it move first?
  • Is there a date by which something has to work, such as a new obligation in invoicing?

How else to tell that a system is not just old but at its end is described in the guide Signs that your system is at its end. How a replacement without a cut-over date works is shown on our page on replacing old systems.