Public Sector ERP Modernisation - Frequently Asked Question

ERP modernisation in the public sector means replacing legacy finance, HR, payroll and procurement systems -typically on-premise, often decades old -with a modern cloud platform that integrates those functions into a single, continuously updated system of record. For a local authority or NHS trust, this typically involves replacing systems that have accumulated years of workarounds, manual processes and bespoke customisations that make them expensive to maintain and impossible to extend. The modernisation is triggered by one or more of three pressures: the legacy system approaching end of support, the organisation’s audit position becoming untenable due to data quality or control gaps, or a structural change -local government reorganisation, an NHS trust merger -that makes separate legacy systems unworkable. The distinction that matters most is between replacing a system and changing how the organisation works. Modernisation that only achieves the former -the same processes running on newer software -delivers a fraction of its potential value and sets up the post-go-live operating model for long-term Transformation Erosion. The organisations that realise lasting benefit are those that use the ERP transition as the occasion to redesign their operating model around the system’s capabilities, rather than configuring the system around legacy ways of working.

The failure pattern in public sector ERP modernisation is consistent enough to be considered structural rather than exceptional. Birmingham City Council’s Oracle Fusion implementation is the most publicly documented recent case: the costs grew from an initial £19m towards a total estimated at around £216m by 2026 (Sheffield University’s Audit Reform Lab). Planned for December 2020, the programme slipped to an April 2022 go-live, with full functionality and remediation running for years afterwards. It is not unique in kind, only in scale and visibility. The causes are well-evidenced. The governance-expertise gap is the most fundamental: public sector leadership teams typically undertake one major ERP programme per decade, while system integrators run dozens. That asymmetry means the client organisation is rarely equipped to function as an intelligent customer -to challenge SI claims, identify scope creep early, or enforce contractual accountability when delivery falls short. The “adopt not adapt” principle is violated consistently. Organisations commit at procurement stage to adopting Oracle’s standard processes, then incrementally accept customisations during implementation when standard processes meet resistance from operational teams. Each customisation adds cost, complexity and future upgrade risk. By go-live, the system reflects the legacy operating model rather than the modern one the business case promised. Independent governance is absent or too late. In Birmingham’s case, no Internal Audit review was conducted until shortly before go-live; by that point, the cost and complexity of the problems identified made remediation extraordinarily difficult. The organisations that avoid this pattern build independent oversight into programme governance from the start, not as a late-stage review.

“Adopt not adapt” is the design principle that public sector organisations should configure their Oracle Fusion implementation to match Oracle’s standard processes, rather than customising Oracle to match their existing ways of working. It is endorsed by every credible ERP adviser, included in most public sector procurement frameworks, and violated in the majority of implementations. The reason it is difficult to implement is organisational rather than technical. Oracle’s standard processes are well-designed and efficient. But they look different from the processes a Finance Manager or Payroll Manager has run for ten or fifteen years. When a user in a design session sees a standard Oracle process that does not match their current workflow, the natural response is to request a configuration change. SIs, under pressure to maintain client satisfaction and programme momentum, tend to accommodate these requests rather than challenge them. Each accommodation is individually justifiable. Collectively, they accumulate into a customised implementation that costs more to build, takes longer to test, breaks more frequently during quarterly updates and is harder to support post-go-live. The organisation has paid for Oracle’s standard capability and received a bespoke version that carries all the fragility of bespoke software without the flexibility of truly custom development. Enforcing “adopt not adapt” requires someone on the client side who has the authority, the Oracle knowledge and the independence from delivery pressure to say no. That is the structural role of an independent adviser in design-stage ERP governance -not to block progress, but to ensure that accommodations are genuinely necessary rather than the path of least resistance.

The UK government’s local government reorganisation (LGR) programme -under which most new unitary authorities are targeted to go live on 1 April 2028, with Surrey a year earlier on 1 April 2027, and decisions for the remaining areas still being confirmed through 2026 -is creating one of the most significant ERP decision windows the sector has seen in a generation. For councils undergoing LGR, the technology estate is one of the most complex elements of reorganisation. When district councils aggregate into new unitary authorities, or when county councils disaggregate, the finance, HR, payroll and procurement systems of the constituent organisations need to either consolidate or separate. In most cases, the legacy systems involved were built independently over decades using different data models, different chart of accounts structures and different process designs. Bringing them together -or dividing them -is not a data migration exercise. It is a modernisation programme under structural pressure and compressed timescale. Organisations that have already modernised to Oracle Fusion Cloud are significantly better positioned for LGR, because Oracle’s standard data model and cloud architecture are designed for reorganisation at scale. Organisations still running on-premise legacy systems face a more difficult choice: attempt to consolidate legacy systems ahead of reorganisation (expensive, complex, and likely to miss the deadline), or use the reorganisation as the occasion for a properly planned ERP modernisation. The risk in both cases is treating LGR as primarily a structural question and discovering, once the structural decisions are made, that the technology estate cannot support them. The organisations managing this well are those that have brought technology strategy into the LGR planning process from the outset, rather than treating it as an implementation detail to be resolved later.

The governance structure needs to perform three functions simultaneously: directing the programme toward the right outcomes, managing the SI relationship with sufficient authority to enforce accountability, and providing the programme sponsor and S151 Officer with an honest, independent view of delivery reality. Most public sector ERP governance structures perform the first two functions with varying degrees of effectiveness. The third -genuinely independent oversight -is the most consistently absent, and the most consistently consequential when things go wrong. At programme board level, effective governance requires: a named Senior Responsible Owner with documented authority and clear accountability for programme outcomes; a Programme Director on the client side who has ERP delivery experience, not just project management credentials; and an independent adviser whose reporting line goes directly to the programme sponsor rather than through the SI. At working level, effective governance requires: a decision log that captures who authorised what and when; a change control process that enforces genuine scrutiny of scope changes rather than accommodating them by default; a design authority that challenges “adapt” requests against the “adopt” principle; and a risk register that is reviewed, not just maintained. The 3-in-a-Box model -client, SI and independent adviser as three distinct voices in programme governance -is the structural design that resolves the expertise asymmetry between the client and the SI. Without the third voice, the client is effectively relying on the SI to self-report its own delivery performance.

Most public sector ERP business cases overstate benefits and understate costs in consistent and predictable ways. Understanding the pattern is the first step to producing a business case that survives contact with delivery reality. Benefits are overstated because they are calculated against the current-state operating model, not the post-go-live one. If the implementation does not change how finance, HR and payroll processes work -if it merely replaces the software -the efficiency benefits do not materialise. A business case that assumes several hundred business processes will be tested, the system will go live, and headcount will reduce accordingly is almost never realised without deliberate operating model redesign and sustained change management. Costs are understated because the business case typically excludes four categories that are consistently significant in delivery: the ongoing cost of quarterly update management (in our experience between £50,000 and £150,000 per cycle for a manual testing approach); the cost of internal resource backfill during implementation (SMEs pulled from operational roles for months have a replacement cost that rarely appears in the business case); the cost of data remediation (data quality issues discovered during migration are consistently more expensive to resolve than estimated); and the cost of parallel running (running legacy and new systems simultaneously for longer than planned is routine and expensive). A realistic business case stress-tests benefit assumptions against what actually changes about the operating model, not what theoretically could. And it includes a post-go-live cost model that reflects the quarterly update cycle, ongoing system support, and the investment required to realise the benefits the case promises.

ERP adoption in the public sector is consistently measured by the wrong indicators. Licence utilisation, training completion rates and help desk ticket volumes tell you whether users have access to and awareness of the system. They do not tell you whether the system has displaced legacy ways of working. Meaningful adoption is measured by output, not input. The indicators that matter are transaction volumes by function and module: are purchase orders being raised in Oracle or in email-and-spreadsheet workarounds? Is the monthly payroll running through Oracle’s payroll engine or being supplemented by manual adjustments? Are journals being posted through Oracle’s journal entry workflow or loaded as spreadsheet imports? Are OTBI reports being used for management decision-making, or are teams maintaining parallel Excel models? In a local authority context, the adoption benchmark that matters most to a Director of Finance or S151 Officer is whether the statutory accounts can be produced from Oracle’s data without significant manual reconciliation. If the answer is no -if the closing process still requires spreadsheet bridges, data extracts and manual adjustments -the system has not been adopted in any meaningful sense, regardless of what the licence utilisation dashboard shows. Measuring adoption at this level requires someone with the Oracle knowledge to interpret usage data in functional terms, not just system administrators counting logins. It also requires the political will to surface adoption gaps honestly rather than reporting training completion as a proxy for readiness.

The most important structural decision in public sector ERP modernisation is not which system to select -it is how to manage the SI relationship once the implementation begins. SI accountability requires three conditions to function. The client must have sufficient technical knowledge to evaluate what the SI is delivering. The contract must contain enforceable accountability mechanisms -milestone-based payments, defined quality gates and clear remedies for non-delivery. And someone on the client side must have the authority and independence to invoke those mechanisms when needed. Most public sector ERP programmes satisfy none of these conditions fully. The knowledge gap is often addressed by hiring experienced SI resource, which creates a conflict of interest. The contract mechanisms exist but are rarely invoked, because doing so damages the relationship and risks programme disruption. And the authority to act sits with programme directors who are simultaneously responsible for delivery momentum -making escalation politically costly. The solution is structural: an independent adviser who sits outside the delivery relationship, whose mandate is programme health rather than delivery velocity, and who can give the programme sponsor an honest assessment of SI performance without the political constraints that affect the internal team. This is not adversarial. A well-functioning independent assurance relationship benefits the SI as well as the client -delivery that is independently validated carries more weight than self-reported progress. Specific accountability mechanisms that should be in place from day one: weekly evidence review (not status updates), a defined defect-resolution SLA that is tracked and reported, milestone-payment certification by an independent party rather than by the SI, and a named escalation path that reaches the programme sponsor directly.

The most common post-go-live failure modes fall into three categories, and they tend to compound each other over time. Workaround accumulation is the first and most pervasive. Every implementation goes live with a set of known gaps -functionality that was descoped, processes that were not configured in time, integrations that were deferred. Each gap generates a workaround. Workarounds that are not documented, reviewed and assigned a resolution path become permanent features of the operating model within months of go-live. By twelve months post-go-live, the typical public sector Oracle programme is running a significant number of workarounds that nobody has formally reviewed since they were introduced. Quarterly update regression is the second. As described in the Oracle Fusion Change Confidence pillar, Oracle’s four annual updates require structured regression testing that most post-go-live programmes are not resourced or equipped to conduct properly. Missed testing leads to post-update failures; post-update failures erode user confidence; eroded confidence generates more workarounds and parallel processes. Benefit erosion is the third, and the most damaging in the long run. The efficiency gains that justified the ERP investment -reduced manual effort, faster close cycles, improved data quality -depend on the operating model actually changing. Where adoption is incomplete and workarounds are prevalent, benefits erode. The organisation ends up running a modern cloud platform with a legacy operating model layered on top, paying the full cost of Oracle and the residual cost of the manual processes it was supposed to replace. These three failure modes are interconnected: workarounds undermine adoption, poor adoption undermines quarterly update confidence, and the combination produces benefit erosion. Addressing any one in isolation does not resolve the pattern. What is required is a post-go-live operating model that owns the workaround register, governs the quarterly update cycle, and measures adoption by output rather than input.

For a local authority, the relationship between ERP modernisation and statutory financial reporting is direct, consequential and frequently underestimated in programme planning. The statutory accounts of a local authority are the primary output of its finance system. The Accounts and Audit Regulations require that accounts are prepared to a standard and timetable set by the relevant code of practice. External auditors assess both the accounts themselves and the controls over the systems that produced them. Where an ERP modernisation has been handled poorly -data quality issues, configuration errors, incomplete adoption -the impact surfaces first and most visibly in the accounts and the audit process. Birmingham City Council made this dynamic explicit at a scale rarely seen. The council formally issued its 2023 Section 114 notice citing an equal-pay liability of around £650m–£760m -but independent analysis has found that the Oracle implementation’s failures, which left the council unable to produce auditable accounts, were a material underlying factor that the notice understated. The lesson for other councils is not that Oracle Fusion is unreliable -it is that an ERP implementation without independent governance and structured testing creates statutory reporting risk that is not confined to the IT department. A well-governed Oracle Fusion implementation should produce statutory accounts with less manual effort than a legacy system, because Oracle’s financial close module, OTBI reporting and budgetary control capabilities are specifically designed for the local government reporting framework. Achieving that outcome requires that the system is adopted properly, the quarterly update cycle is managed, and the data model reflects the council’s actual financial structure -none of which happens without deliberate governance and assurance throughout the programme lifecycle.

The core ERP modernisation challenge -replacing legacy systems, managing SI relationships, governing quarterly updates -is common across public sector and regulated-sector organisations. The sector-specific differences lie in regulatory framework, funding complexity, and the specific Oracle modules that are most critical. For universities, the primary Oracle modules of concern are Finance and Procurement (research grant accounting, complex VAT recovery, international supplier payments), HR and Payroll (academic pay scales, the USS pension scheme, REF reporting), and increasingly Oracle Analytics for student data and research income modelling. The regulatory framework is the Office for Students rather than local government audit requirements, but the governance principles are identical -the OfS expects universities to demonstrate effective financial control and risk management in their digital systems. For housing associations, the primary concern is financial compliance under the Regulator of Social Housing’s Consumer and Economic Standards, combined with the specific Oracle configuration required for stock accounting, void management and social housing VAT. Housing associations are also affected by the quarterly update cycle in specific ways -payroll changes, VAT treatment updates and reporting format changes that interact with regulatory submissions. The common thread across all three sectors is that the ERP investment is justified by efficiency, control and reporting quality -and in all three, those benefits depend on implementation quality, ongoing governance and structured management of the quarterly update cycle. The sector-specific configuration requirements vary; the governance requirements do not.

SIM Consulting’s approach to public sector ERP modernisation is grounded in two decades of direct delivery experience in UK local government and regulated-sector environments -not in advisory frameworks applied from a distance. Ramzan Amin led the Kent County Council transition from a 23-year legacy system to Oracle Fusion Cloud, delivering around £4m in annual savings on one of the UK’s largest local authority modernisations. That programme experience -understanding what breaks, what the SI relationship looks like under pressure, and what the S151 Officer needs to be able to say to external audit -informs every SIM engagement. In practice, SIM provides independent oversight across three phases. Pre-implementation: reviewing business case assumptions, governance design and contract structure before the SI relationship begins -the lowest-cost point at which programme risk can be shaped. During implementation: providing the programme sponsor with an independent view of delivery reality, challenging scope changes, and reviewing the “adopt not adapt” position at each design stage. Post-go-live: assuring the quarterly update cycle, auditing workaround registers, measuring adoption by output, and providing the evidence base the Director of Finance needs for statutory reporting confidence. SIM is independent. We have no financial relationship with any system integrator and we do not resell Oracle licences. Our commercial relationship is with the organisation we are assuring -which means our findings go directly to the programme sponsor without being filtered through the SI’s interests. For organisations beginning to scope an ERP modernisation, or those already mid-programme and concerned about delivery trajectory, SIM’s ERP Governance Diagnostic provides a structured starting point. It takes 15 minutes and surfaces the governance positions a programme should be able to confirm. Available without obligation at simconsultingltd.com.