Legacy Modernization Is Not a Technology Project

Every five to seven years, a familiar ritual plays out in the boardrooms of African financial institutions. The core banking system, or the ERP platform, or the risk management infrastructure, reaches a point where its limitations become intolerable. Response times degrade. Integration with newer systems becomes prohibitively expensive. The vendor announces end-of-life for the current version. Regulators introduce requirements that the existing architecture cannot accommodate. The board approves a modernization programme. The CIO selects a new platform. The implementation begins. And then, with remarkable consistency, the project delivers less than promised, costs more than projected, and takes longer than planned.

The failure rate of large-scale legacy modernization in African enterprises is staggering. Estimates vary by source, but the consensus is that between 55 and 70 percent of major system replacement projects in African financial services fail to achieve their stated objectives within the original timeline and budget. Among those that eventually deliver, the average cost overrun is 45 percent, and the average timeline extension is 18 months. These are not statistics from troubled or poorly managed institutions. They are industry averages that include some of the continent's best-run organisations.

The standard explanation for these failures focuses on technology: the new system was more complex than expected, integration with existing infrastructure proved difficult, data migration was underestimated. These explanations are not wrong, but they are incomplete. They describe symptoms rather than the underlying condition. The underlying condition is that legacy modernization is treated as a technology project when it is, in fact, an organisational transformation project in which technology is one of several equally critical and interdependent workstreams.

The Technology Tunnel Vision

When an organisation frames legacy modernization as a technology project, it naturally organises around technology deliverables. The project plan centres on system configuration, data migration, integration development, and user acceptance testing. The project team is dominated by technologists — systems architects, database administrators, integration specialists, and vendor consultants. The budget allocation reflects this framing: typically 70 to 80 percent of the total budget is allocated to technology activities, with the remainder split between training, change management, and contingency.

This framing creates a series of predictable failures. The first is process inheritance. When the technology team configures the new system, they configure it to replicate the processes of the old system. Why? Because the processes are what the users know, the processes are what the training materials describe, and the processes are what the acceptance testing validates. No one has been tasked with — or budgeted for — the work of examining whether those processes should survive the migration.

The result is a new system running old processes. The technology is modern. The workflows are legacy. The organisation has spent $10 or $20 million to achieve what is functionally a cosmetic upgrade — a new interface on old operational logic. The inefficiencies, the workarounds, the redundant controls, and the process debt that accumulated over the life of the old system have been faithfully replicated in the new one. Within two years, the same complaints surface: the system is slow, inflexible, and does not support the business as it needs to operate.

The second failure is organisational unreadiness. The technology is ready. The people are not. The new system requires different skills, different workflows, different decision processes, and different data practices. A core banking system migration does not just change the software — it changes how tellers process transactions, how credit officers evaluate loans, how compliance officers produce reports, and how branch managers monitor performance. These are not cosmetic changes. They are fundamental shifts in daily work practice that require sustained training, coaching, and support to embed effectively.

When 75 percent of the project budget is spent on technology and 5 percent on training, the technology goes live and the organisation is not ready to use it. Staff revert to workarounds. Data quality degrades as people enter information incorrectly in the unfamiliar system. Processing times increase rather than decrease as users navigate interfaces they have not had time to learn. Customer complaints spike. The project team scrambles to provide additional support, diverting resources from the remaining implementation phases. The timeline extends. The budget overruns. The board wonders what went wrong.

The third failure is governance misalignment. Legacy modernization changes the organisation's operating model, its risk profile, and its control framework. But because the project is framed as a technology initiative, governance is handled by the technology steering committee, and the organisation's business governance structures — the risk committee, the compliance function, the audit committee — engage only peripherally. By the time these governance bodies realise that the new system has fundamentally altered how the organisation manages risk, produces regulatory reports, or maintains audit trails, the changes are embedded and difficult to reverse.

The Five Workstreams of Modernization

A successful legacy modernization programme treats the technology migration as one of five interdependent workstreams, each of which receives proportional leadership, budget, and executive attention.

The first workstream is technology — the platform selection, configuration, data migration, integration, and testing that the traditional approach correctly includes. This workstream should receive approximately 40 to 50 percent of the total programme budget, not 70 to 80 percent. The reduction does not reflect a lower technology cost; it reflects a more honest accounting of the total cost of successful modernization.

The second workstream is process redesign. Before the new system is configured, every process that will operate on the new platform should be examined, rationalised, and redesigned. This means mapping current processes in detail, identifying and eliminating process debt, designing target-state processes that leverage the new platform's capabilities rather than replicating old workflows, and documenting the process changes that users will need to adopt. This workstream should receive 15 to 20 percent of the total programme budget and should be completed in advance of system configuration so that the technology team configures the system to support the redesigned processes, not the legacy ones.

The third workstream is people and capability. This encompasses not just end-user training — which is where most organisations stop — but organisational design, role redefinition, competency assessment, capability building, and ongoing support. If the new system changes how work is done, the people doing the work need to understand why the change is happening, what their new role looks like, what skills they need to develop, and how they will be supported during the transition. This workstream should receive 15 to 20 percent of the total programme budget and should begin before the technology goes live, not after.

The fourth workstream is governance and risk. This involves updating the organisation's control framework, risk management policies, regulatory reporting processes, and audit procedures to align with the new operating model. It includes identifying new risks introduced by the new platform — cybersecurity considerations, data privacy implications, model risk if AI components are included — and ensuring that the governance structure is prepared to manage them. This workstream should receive 5 to 10 percent of the total programme budget.

The fifth workstream is change management and communications. This is the connective tissue that holds the other four workstreams together. It encompasses stakeholder communication, executive alignment, cultural change initiatives, resistance management, and programme-level coordination. It ensures that the technology team, the process redesign team, the people team, and the governance team are aligned on objectives, sequencing, and dependencies. This workstream should receive 5 to 10 percent of the total programme budget.

The Process Redesign Imperative

Of the five workstreams, process redesign is the one most consistently neglected and the one most directly correlated with programme success. Research by McKinsey on enterprise system implementations found that programmes that included comprehensive process redesign achieved 2.5 times the benefit realisation of programmes that migrated existing processes to new platforms. The difference was not attributable to better technology choices or higher budgets — it was directly attributable to the elimination of process debt during the migration.

Process redesign during legacy modernization is uniquely powerful because it leverages a natural disruption. When the old system is being replaced, the inertia that normally protects legacy processes from scrutiny is temporarily suspended. Staff expect change. They know that the new system will work differently. They are psychologically prepared for new workflows in a way that they never are during routine process improvement initiatives. This window of opportunity — the organisational openness that accompanies a system migration — is the single best moment to address process debt that would otherwise persist indefinitely.

A Nigerian bank that recognised this during its 2022 core banking migration allocated 18 percent of its programme budget to process redesign — compared to the industry average of approximately 5 percent. The process redesign team examined every major workflow that would operate on the new platform and redesigned each one from first principles: what outcome does this process need to produce, what is the minimum set of steps required to produce that outcome reliably, and how can the new platform's capabilities be leveraged to eliminate manual interventions that the old system required?

The results were striking. The bank eliminated 34 percent of its total process steps across the workflows examined. Loan origination went from 28 steps to 16. Account opening went from 19 steps to 11. Regulatory reporting went from a 5-day monthly process to a 1.5-day process, with the new system generating 80 percent of the required outputs automatically. The process redesign investment of $2.1 million generated an estimated $8.7 million in annual operational savings — a return that dwarfed the savings attributable to the technology migration itself.

The Capability Investment

The people and capability workstream deserves particular attention because its failure mode is the most insidious: it fails silently. A technology migration that goes wrong produces visible symptoms — system errors, integration failures, data corruption. A capability investment that is inadequate produces no visible failure. The system works. The people appear to be using it. The reports generate. But beneath the surface, staff are operating at a fraction of the system's capability, using workarounds to compensate for features they do not understand, and gradually reverting to manual processes that feel safer than the unfamiliar digital workflows.

The signs of this silent failure include system utilisation rates that plateau well below target, data quality metrics that do not improve despite a new system designed for better data capture, and a growing gap between the system's documented capabilities and the capabilities that staff actually use. By the time these signs are visible, the window for effective intervention has typically closed — staff have established their comfort zone with the new system, and changing their established patterns is as difficult as changing the patterns they had with the old system.

Preventing this failure requires front-loading capability investment. Rather than training staff after the system goes live — the standard approach — effective programmes begin capability building six to twelve months before go-live. Staff learn the conceptual framework of the new processes before encountering the new system. They develop proficiency with the new tools in training environments before facing production pressures. They build confidence gradually, with coaching support, rather than being thrown into a new system under operational stress.

The Integration Challenge

Perhaps the most important insight from successful legacy modernization programmes is that the five workstreams are not independent. They are deeply interdependent, and the failure to manage their dependencies is a primary cause of programme failure.

Process redesign must inform technology configuration. If the new system is configured before processes are redesigned, the technology team will configure it for legacy processes, and the redesigned processes will require expensive reconfiguration. People and capability development must align with process redesign. If staff are trained on legacy processes and then told to adopt redesigned processes, the training investment is wasted and staff frustration intensifies. Governance updates must track both process and technology changes, or the organisation will face a governance gap during transition.

Managing these dependencies requires a programme management capability that transcends any individual workstream. It requires a programme leader who understands technology, process, people, governance, and change management — and who has the authority to make trade-offs across all five dimensions. In most African enterprise modernization programmes, this role does not exist. The CIO manages the technology workstream and has limited authority over process redesign or people development. The project management office coordinates timelines but does not manage dependencies across workstreams. The result is five workstreams that are individually managed but collectively uncoordinated — a structural flaw that virtually guarantees suboptimal outcomes.

Legacy modernization is not a technology project that happens to involve some organisational change. It is an organisational transformation project that happens to involve technology. The organisations that understand this distinction — and staff, fund, and govern their modernization programmes accordingly — achieve dramatically better outcomes than those that do not. The technology is the most visible component. It is not the most important one.