Written By
Rodrigo Azziani
Published
May 22, 2026
Last updated
When an IT manager at an Argentine bank raises the idea of modernizing the core, the first thing they hear is a list of reasons why now is not the time. Regulation can't wait. The systems are in production. The team doesn't have the capacity. And at some point during the year, Argentina's Central Bank (BCRA) issues a circular that reshuffles the priorities of the entire department.
That resistance isn't unreasonable. In Argentine banking, the systems that sustain critical operations have spent decades accumulating dependencies nobody ever fully documented, processes nobody dared to touch, and architecture decisions that made sense at the time but now operate as invisible constraints. Modernizing in that context is not the same as modernizing at a startup that can afford two hours of downtime.
Which is why the question is not whether to modernize — that decision has already been made for most organizations in the sector — but how to do it without stopping what cannot stop.
Most banking modernization projects fail before they get off the ground, because the diagnosis was superficial. The team identifies the systems it wants to replace, puts together a timeline, defines the target technologies, and gets started. What it fails to map in enough detail is the graph of real dependencies: which system depends on which, under what conditions, and what fails first if something goes wrong.
In banking, that graph is usually denser than it looks. A settlement system doesn't just process transactions: it feeds regulatory reports, connects to external clearing systems, has interfaces with users' own terminals, and in several cases holds business logic that was never documented because the person who knew it no longer works at the organization.
Before defining any technical strategy, you need to answer three concrete questions about each candidate system:
The answers determine the strategy more directly than any technology criterion.
There is no single way to modernize a banking core. Depending on the diagnosis, an organization can take three different paths, and the decision should follow concrete criteria, not technology preferences.
Replacing makes sense when the system has limited dependencies, the business logic is documented or can be surveyed, and there is a migration window the business can tolerate. It also applies when the cost of keeping the system in production far exceeds the cost of replacing it — something that has to be calculated explicitly, not assumed.
Encapsulating is the right strategy when the system has too many dependencies to replace in one go, but the organization needs to expose its capabilities to new consumers: a mobile application, an API for third parties, a real-time analytics system. Encapsulation builds a modern interface layer on top of the existing system without touching it, making it possible to move forward without halting operations. The risk of this strategy is deferring technical debt without eliminating it; you need to be clear about that from the start, because otherwise it shows up as a surprise two years later.
Leaving it alone is a valid decision, not a capitulation. If a system is stable, has critical dependencies that would make any intervention very costly, and doesn't block any priority business initiative, the best decision may be to leave it where it is and modernize what surrounds it. The mistake is assuming that modernizing means replacing everything.
In practice, well-designed projects combine the three strategies according to each system's profile. There is no single answer for the entire infrastructure.
For IT teams in Argentine banking, regulation isn’t an external factor that complicates the project: it’s part of the design from the start. Two dimensions directly shape the technical strategy.
The first is availability. Systems that process operations subject to BCRA rules have response-time and availability constraints that are non-negotiable. Any modernization architecture has to guarantee those systems won’t go out of service for periods that put compliance at risk. That isn’t a requirement you bolt on at the end: it determines from day one what kind of rollout is possible and how much parallelism you can sustain during the migration.
The second is traceability. Regulation requires certain events to be auditable: who did what, when, and with what result. If modernization means changing how those events are recorded—migrating to a new logging system, modifying the audit data model—that change has to be coordinated with compliance before the first commit, not after the system is already in production.
Treating regulation as a constraint to work around is the fastest way to create problems that take months to resolve. Treating it as a design parameter from the start completely changes the kind of architecture you end up proposing.
Beyond the technical strategy, banking modernization projects that reach production without critical incidents share a few patterns.
The first: the team that knows the legacy system participates actively in the design. The knowledge of how that system behaves under real load, which exceptions it handles that appear in no document, and which edge conditions produce unexpected behavior lives in the heads of the people who work with it every day. If that knowledge isn’t transferred in a structured way at the start of the project, it shows up as a critical production bug six months later.
The second: the rollout strategy is defined before the first line of code is written. For banking, that usually means gradual migration with rollback capability: a slice of traffic goes to the new system, gets monitored, and only once its behavior is validated in production does the percentage increase. It isn’t the fastest strategy, but it’s the one that brings risk down to manageable levels.
The third: success is defined in terms the business understands, not just the technical team. Reducing technical debt is not a business goal. Cutting the time to integrate a new provider from a month to a week is. Enabling a new product offering without depending on a six-month release cycle is too. When the technical team can articulate impact in those terms, it earns the backing that projects of this scale inevitably need.
Regulation isn't a constraint to work around: it's a design parameter. Treat it as the former and the problem shows up in production, not before.
Rodrigo Azziani
If you’re evaluating a core modernization project and still aren’t sure where to begin, the first step isn’t choosing the technology: it’s mapping the real dependencies of your critical systems and classifying them against the three criteria above.
Done rigorously, that diagnosis takes two to four weeks. And it’s the difference between a project that reaches production on schedule and one that drags on indefinitely because every week something surfaces that nobody knew was there.
None of this is work a banking IT team should—or can—tackle in isolation. Dependency mapping, a rollout strategy with rollback, and coordination with compliance all require specific experience modernizing critical systems. If your organization is weighing this kind of project, at Renaiss we offer cloud consulting for companies operating under local regulation, with production systems running and no room to stop the business.
© 2026 - Renaiss with love