Independent technical oversight for core banking migrations: why a second set of eyes lowers risk

By the Redsis Consulting & Infrastructure team · October 2026 · 6 min read

A large financial system, a core that can't fail

Colombian banks hold roughly COP 1,000 trillion in assets, according to La República's ranking of the country's largest companies based on year-end 2024 figures. Much of that activity runs, at some point, through mission-critical platforms such as IBM i on IBM Power, which Latin America's large banks choose for stability and high-volume transaction processing.

Refreshing those platforms is necessary: each processor generation brings more capacity, better efficiency and new security features. For Power10, IBM highlights transparent memory encryption and four times as many crypto engines per core as Power9. But migrating is not just swapping boxes. The core partition drags along storage, SAN, multipathing, zoning and replication to the DR site. A mistake in any of those layers can derail a cutover window that was flawless on the compute side.

What technical oversight is (and isn't)

A technical overseer is an independent third party that reviews, monitors, analyzes and raises alerts on the work of whoever is delivering the project. Its value lies in independent judgment: it doesn't build the solution or compete with the contractor, and it doesn't replace the project owner as decision-maker.

In this engagement, the model was set from day one:

• The contractor performs the migration, owns the migration, cutover and rollback plans, and delivers evidence.
• The overseer reviews that evidence, identifies risks, and issues alerts and well-supported technical opinions.
• The bank decides: it accepts, rejects, gives the go/no-go and releases milestones.

That separation looks obvious on paper, but in practice it is what prevents two equally costly extremes: an overseer that becomes a bureaucratic bottleneck, and one that ends up doing the contractor's job without owning the outcome.

Joining a project that is already 70% done

One distinctive feature of this engagement was timing. The migration was already approved and about 70% complete, 20 partitions had previously been moved to Power10, and the target was 54% more compute capacity for the core. The most delicate piece, the core banking partition, was still ahead, and the engagement had to deliver value in a single month.

Coming in late has an upside and a risk. The upside is history: tests already run, lessons learned and a team that knows the platform. The risk is assuming everything that came before is fine without checking. So the first task was to agree with the bank on the technical criteria the evidence would be measured against, and to set up a log of information requested versus received.

Six practices that make technical oversight useful

1. Agree on criteria before giving opinions

A technical opinion is only defensible if everyone knows what it is being measured against. If the bank has formal acceptance criteria, adopt them; if not, the overseer proposes a standard set for IBM Power migrations and gets it agreed in the first week or two.

2. Keep score on information

A requested-versus-received log sounds like paperwork, but it is the best defense against gray areas. If a piece of evidence never arrived, it is on record, and the risk gets managed instead of ignored.

3. Look beyond the server

In a core migration, compute is usually the best-documented part. Storage, SAN, multipathing, zoning and DR replication deserve the same scrutiny, because that is where cutover-night surprises tend to hide.

4. Review the rollback as seriously as the cutover

Everyone reviews the plan to move forward. Far fewer test the plan to go back with the same rigor. A clear rollback, with trigger criteria and realistic timings, is what lets a bank commit to the window with confidence.

5. Put everything in writing, on time

This engagement defined 15 formal deliverables: kickoff minutes, work plan, baseline report, a risk register updated weekly, a KPI tracking dashboard, weekly reports, event-driven technical opinions, formal alerts, a conformity opinion on the cutover window, a final report, a final risk and findings register, recommendations and close-out minutes. Traceability is what turns an opinion into a governance input.

6. Be there when it matters

Much of the review work can be done remotely. But at critical milestones, such as the cutover preparation session or the window itself, being on site makes a real difference to the quality of the technical conversation.

What the bank gains

Well-designed technical oversight doesn't add layers; it adds clarity. The bank reaches every cutover decision with an independent, documented and well-supported opinion. The contractor gets early feedback on gaps that are better closed before the window than during it. And the organization keeps a record of risks, findings and recommendations that pays off in the next migration.

All of this without touching the chain of command: the final decision always stayed with the bank, which is exactly where it belongs.

Where to start

If your institution has a critical platform migration underway, whether servers, storage or a data center move, it is worth asking who is independently reviewing the evidence before each window. At Redsis we combine more than 25 years of mission-critical infrastructure experience in Latin American banking with deep IBM Power and IBM i expertise, and we put that expertise to work for the bank, not the tool.