Migrating to cloud at an Argentine fintech is not the same as migrating to cloud

There's a conversation that keeps repeating. An Argentine fintech with three or four years in operation, a proven product, a growing customer base, reaches the point where infrastructure starts holding the business back. The technical team knows it's time to move to the cloud. They secure the budget. They hire a consultancy — sometimes a global firm, sometimes a freelance team — and the migration begins.

Six months later, the project has stalled. Not because of technical problems. Because of problems the initial architecture never accounted for, because nobody on the team asked about them before writing the first line of Terraform.

This isn't an anomaly. It's the most common pattern in cloud migrations at Argentine fintechs, and the cause is almost always the same: assumptions from a North American or European context were applied to an operation with completely different regulations, data restrictions and market conditions.

The BCRA is not optional

A fintech operating in Argentina under the regulation of the Argentine Central Bank (BCRA) faces concrete restrictions on where its customers' data can reside. Comunicación A 7724 and the payment services regulations define frameworks that condition everything from which AWS or GCP regions you can use to how you have to structure access and audits. These aren't obstacles to work around — they're compliance requirements that, if not built into the architecture from the start, generate costly rework or outright block the operation.

The problem is that most cloud architecture resources available online start from American or European assumptions. The AWS Well-Architected Framework, certification courses, reference white papers — all of them useful, but none of them tells you what to do when your architecture has to comply with BCRA regulations while staying flexible enough to adapt to the regulatory updates that, in Argentina, arrive with a frequency unmatched in other markets.

That has a practical consequence: the consultancy that knows a lot about cloud but little about Argentine financial regulation will hand you an architecture that is technically correct but can't go to production.

What changes when the context is local

A well-executed cloud migration at an Argentine fintech has to solve three problems simultaneously that in other markets are usually independent.

The first is technical: moving the workload so the system becomes more reliable, easier to scale and cheaper to operate over the medium term. This is what most consultancies offer. It's necessary but not sufficient.

The second is regulatory: making sure the resulting architecture complies with current regulations and has the flexibility to adapt to changes. This requires knowing today's rules, having a read on where they're headed, and knowing how to translate legal requirements into architecture decisions. It's not the job of a lawyer or a cloud architect working separately — it's the job of someone who speaks both languages.

The third is operational: the internal team must be able to run the new infrastructure without depending indefinitely on external support. A migration that leaves the client unable to operate what was built isn't a successful migration — it's a new dependency under a different name.

All three problems have to be solved before the project ends. If any of them is left pending, the technology team pays for it, usually in the form of an incident at the worst possible moment.

‍

‍

Why size is not the deciding factor

There's a belief embedded in the Argentine fintech ecosystem that associates cloud migration with large companies. The logic is that you need to reach a certain transaction volume or team size for the investment to be worth it.

That logic is wrong, and the mistake lies in how "worth it" gets defined.

A fintech with 50,000 active customers running on its own on-prem infrastructure carries a real opportunity cost: the technical team spends a share of its time maintaining that infrastructure, and that time never turns into product. That cost is invisible on the balance sheet, but it exists. When the migration is done well, that time is recovered. The engineering team gets to build features instead of maintaining servers.

The case for migrating isn't current volume — it's the cost of the status quo compared to the cost of running on properly designed cloud infrastructure. In most of the cases we've analyzed, the break-even point arrives sooner than the leadership team estimates.

What makes a migration work

After several projects in the Argentine financial sector — fintechs, wallets, payment companies — a few factors separate the migrations that reach production and run well from the ones that stall or create more problems than they solve.

The first is having someone with real technical authority inside the company involved from the start. Not as a budget sponsor but as a technical counterpart. Migrations where the CTO or Lead Architect actively participates in design decisions have significantly higher success rates than those outsourced entirely.

The second is designing the architecture around who will operate it, not just who will build it. This sounds obvious, but it isn't: many consultancies optimize for delivering something that works at handoff. What matters is that it keeps working six months later, when the external team is gone.

The third is regulatory timing. Argentine fintechs migrating during periods of high regulatory activity — and in Argentina the last three years have been a stretch of constant regulatory activity — have to build in more flexibility than they would in a stable context. That has implications for service choices, data structure and how the architecture is documented for audits.

Migrating an Argentine fintech well is neither a purely technical problem nor a purely regulatory one: it means solving both at once, with the operation running and no room to hit pause. That's what we do in cloud consulting for Argentine companies — architecture that complies with the BCRA, that your team can operate, and that adapts to the regulatory changes that never stop in Argentina.

‍

The conversation worth having earlier

Most of the conversations we have with Argentine fintechs happen once the problem is already visible: infrastructure is holding back a launch, operating costs have grown faster than the business, or an incident exposed a fragility the team knew existed but hadn't had time to fix.

It's better to have it earlier. Not because we're consultants with an interest in generating work — but because the cost of a poorly designed architecture is always higher than the cost of designing it well from the start. Undoing infrastructure decisions in production, with real customers and regulators watching, is the kind of work that never shows up in any budget but ends up appearing all the same.

If your fintech is weighing when and how to migrate to cloud, or if you already started a migration that stalled, let's talk. The first conversation is a review of where you stand today — no commitment and no PowerPoint.

‍