An end-of-maintenance sounds like a deadline for IT to administer. A date in the calendar by which something has to be done. It is exactly this reading that misleads.
SAP has, for understandable reasons, no interest in maintaining two product lines forever. So an end-of-maintenance had to come; by now it has been pushed to 2027, which gives some air but does not dissolve the pressure. The real point lies elsewhere: with the move, databases are not merely swapped; old habits are cut away — redundancies in the application structure, a new interface. This is no ordinary release change. Processes have to be rethought, not just functions found again. A mammoth project, often with higher resistance, because the deadline was waved from the very start.
Early or late is a matter of the company’s character
Whether you move early or late is, in the end, a question of organizational appetite. A company that is set up dynamically, used to transitions, with an IT and a workforce that welcome change, usually has tidy systems and clean processes. It can be there early. The price is a kind of development tax: you are often a development partner, and that costs time and sometimes stability. A structurally conservative company, by contrast, that lets things run until they really hurt and treats IT governance as a stepchild, rarely has the cleanest data. For that one, the later move pays off, once tools and migration roadmaps have matured. Only, with every year of waiting, the run on scarce resources grows — whoever comes too late has to choose very carefully, so as not to end up with the overpriced dregs.
Why this belongs on the board table
IT can only ever answer the question through the technical lens: where does the old system cause trouble, what is appealing about the new features, how long does maintenance still run. But an ERP transition is a whole-organization decision with concrete impact on every area, in setup and in operation. That is why it belongs honestly assessed at board level, in case of doubt by the full board. That secures attention, priority and the backing without which change of this size does not hold.
How can a board anchor the timing, instead of chasing the deadline? Ask the CIO to build a sandbox from production systems and run assessments there: how do code and data really stand? From the result a rough roadmap can be derived — little legacy argues for early, much legacy for some patience. The end date stays set, so it is worth checking code and data continuously and starting to clean up regardless. That way the transition gets easier month by month. The end-of-maintenance is a date. Whether and when you respond to it is your decision.