I have led the JD Edwards estate of a national pension fund in East Africa for nearly two decades: we stabilised it, upgraded it twice, and are now migrating it to Oracle. What changes in an office like that one is the length of the record standing behind every figure.
What the go-live story leaves out
Our industry writes about selections, implementations and go-lives. It writes almost nothing about the years that follow, which is when a system becomes either an institution’s memory or its problem.
A system earns belief as a colleague does, by being right at every close for years. The record accrues one month at a time, and it is lost on the day history is cut off at a migration because carrying it across was judged too expensive.
The vendor’s own commitment supports the long view. Oracle’s published policy makes Premier Support for JD Edwards EnterpriseOne 9.2 available through at least 2037, and Oracle reviews each year whether to extend it further. An estate first installed two decades ago can remain in full support for another decade.
Why a pension fund needs the same answer every month
A pension fund makes a promise that takes forty years to keep. Members want every contribution counted. Auditors want each balance traced to its transactions, and regulators want this year’s return to agree with last year’s. Each of them is asking for one thing: the same answer, every month.
The sums resting on such records have never been larger. The OECD’s Pension Markets in Focus 2025 puts assets earmarked for retirement in its member countries at USD 69.8 trillion at the end of 2024, above the previous record set in 2021. The same report finds Africa holding the smallest pool of any region, and funds there are building now the records their members will lean on for decades. Every account in those totals is a history that someone will one day ask to see in full.
Britain is testing the same point in public this month. The Pensions Regulator requires all schemes in scope to connect to pensions dashboards by 31 October 2026. A connected scheme must match a saver to their record and return their pension information on request, and the regulator’s guidance states that member data must be of sufficient quality to meet those duties. For schemes that kept one continuous record, the deadline is a formality.
Stewardship is a different discipline from replacement
Many boards have absorbed the idea that an ERP should be replaced on a fixed cycle, and that anything older is technical debt. Age is the wrong measure. Debt is a system nobody understands, carrying customisations nobody documented and history nobody can query. A twenty-year-old system that closes cleanly and explains itself is an asset.
Stewardship has its own order of work. Stabilise first, until the close is dull. Upgrade in place while the platform is supported and still fits the business. Migrate when the reason is real: a change in what the institution must do, not a change in fashion.
When we do migrate, the first design question is how the full history travels. The record is what the institution owns. The software is only where it lives.
The record AI will be asked to read
Continuity matters more with every year of AI. A model asked to forecast liabilities, flag an unusual contribution pattern or answer a member in plain language is only as good as the history it can read. Twenty years of consistent coding, with the chart of accounts mapped forward at each change and an audit trail without gaps, is what makes its answers defensible. An institution that restarted its data three times has three short memories, and AI will inherit the joins.
Picture a contributor in 2046. She joined the fund in 2006, has changed employer four times, and now asks an assistant on her phone what she has paid in and what it has earned. The answer arrives in seconds and covers forty years. It matches exactly what the auditor, the regulator and the fund’s actuary would be told.
Behind that answer sit two platforms, several upgrades and one record. She never learns the name of either system, and has no need to.
Value the system by the length of its record
Boards usually judge a system by its cost and its age. I would add another measure and rank it first: the length of the unbroken, auditable record. It is the number of years for which the institution can reproduce any balance with its supporting transactions, from the system, without a spreadsheet. That figure belongs in the board pack, and any proposal to replace a system should state what will happen to it.
This quarter, ask your CFO and CIO for that one number, and for a list of every point at which the record breaks: a migration that brought balances without transactions, an archive nobody can open, a recoding with no map. Then decide which breaks are worth repairing before the next change of platform.
An Dependable Core readiness review with NectarGlobal starts from that list. It tells you whether your system needs stabilising, upgrading or moving, and what must travel with it.