vcodevs*

We modernize systems the business cannot switch off.

We recover decades of business logic from legacy systems and move it, step by step, to modern architectures — no big-bang migrations. And we build the new systems that sit on top, knowing how they age.

Assess my system See how we migrated a real system

40+ years legacy · 10+ years banking · COBOL → APIs · PostgreSQL · Django · React · AWS

40+

Years of COBOL analysis

Healthcare · accounting

10+

Years in banking

Citi · Standard Bank · ICBC

Argentine banks integrated

LoanCars · in production

6,000+

Bookings processed

Slope · 3 seasons

vcodevs Legacy Bridge

We don't replace the system.
We work between its layers.

An organization with decades of operation can't switch anything off. The migration comes in parts, in this order.

The starting point

The system works. Touching it is the problem.

Forty years of business logic that runs every single day, and fewer and fewer people who know why. Switching it off isn't an option.

Data comes first

Data migrates before the code.

PostgreSQL in parallel, with integrity verified against the original. Nothing is switched off: both systems run side by side while they're compared.

Then, the translation

A layer that speaks both languages.

APIs that expose what the old system knows how to do, without touching its internals. From there, the new is built against a stable interface.

The surface, last

Only then, the new interface.

Dashboards, reporting and exports on data that is already trustworthy. Users see the change last, once everything underneath is settled.

Your operation

What the business needs today

Interface and reporting

React · dashboards · exports

Interoperability layer

APIs that speak to the old system, live

Migrated data

PostgreSQL · integrity verified

AWS

Your legacy system

Decades of business logic, in production

Where to start

Legacy Assessment

Before proposing a migration, the system has to be understood. In two to three weeks we build the full map: what's there, what depends on what, which business rules are buried in the code, and in what order it makes sense to touch it.

It's a bounded engagement with its own deliverable. If we don't continue afterwards, the map is still yours.

Deliverable

Legacy Modernization Blueprint

2 to 3 weeks · fixed scope

What it covers

01Application inventory

02COBOL / JCL processes

03Dependency map

04Files and databases

05Existing integrations

06Critical business rules

07Operational risks

08Concentrated knowledge points

09Modernization roadmap

10First-migration candidates

11Target architecture

12Time and cost estimate

Capabilities

One core, and what
gets built on it.

The core is modernizing systems that can't be switched off. The other two come out of it: connecting what's left with the rest of the world, and building new product knowing how a system ages. Technology is the tool, not the reason.

CORE

Critical systems modernization

Healthcare and accounting systems with decades of operation that can't be switched off. We recover the business rules, decouple the data and replace it piece by piece. No big-bang.

COBOL · PostgreSQL · interoperability APIs · Django

Financial systems and integrations

Lending, payments, scoring and compliance. Integrations with banks, payment gateways and credit bureaus, with the handling of sensitive data the sector demands.

MercadoPago · Ripsa · Stripe · Equifax · Interconnect

Product engineering

New systems, built by people who have seen what they look like after forty years. Web applications, SaaS, applied AI, cloud and analytics. From MVP to a product in operation.

Django · React · AWS · Vertex AI · Plotly

Work

Projects that hold up
in the real world.

Not demos or prototypes. Products in production, processing transactions and solving real problems.

Entidad Bonaerense de Pagos

Legacy modernizationClient

Migration of a COBOL payments system to a Django web application. A provincial government body with decades of operation and processes that could not be interrupted. The migration came in layers: data first, then interoperability, the surface last.

COBOL → Django · React · PostgreSQL · AWS

2020

in production since

LoanCars

Fintech · Auto financingOur own product

A broker connecting car dealerships with Argentine banks for secured auto lending. vcodevs* runs both the business and the software, so the product was designed against the real operation.

Django · React · PostgreSQL · AWS

Argentine banks integrated

Slope

SaaS · Ski schoolsOur own product

All-in-one platform for ski schools. Instructor management, bookings, drag & drop scheduling, equipment rental and financial reporting. Validated across 3 seasons in real production.

Django · React · PostgreSQL · AWS

6,000+

bookings processed

Narevo

AI · Video marketingClient

Platform that automates video marketing production: from script to social publishing using Google Vertex AI Veo 3 and an end-to-end asynchronous pipeline.

Django · React · Vertex AI · GCP · OpenAI · ElevenLabs

33%

reduction in production costs

Why vcodevs*

We're not a code
factory.

We'retechnicalpartnerswhounderstandthebusiness.Werundiscovery,surfacetherisksandrecommendtherightarchitecturedecisions—beforewritinganycode.

Why waiting increases the risk

Every migration is audited against the original

An analyst with more than four decades in COBOL, specialized in healthcare —clinics, hospitals, health insurers— and in accounting processes, checks that the old system's logic survives in the new one. This isn't a code review: it's an audit of business rules, done by someone who spent forty years writing them.

We've already done the knowledge transfer

The risk that worries you —that only two or three people understand the system— is the one we solve in-house every day. What gets read out of the COBOL ends up in documentation, in tests and in the new code. Not in someone's head.

Real financial background

10+ years in banking — Citi, Standard Bank and ICBC. We understand regulation, compliance and the business logic of the Argentine financial sector.

Our own products in production

Slope and LoanCars show we build with skin in the game. We know what it takes to operate a real product, not just ship it.

Gradual migration, not replacement

We never propose switching one system off to turn another on. Both run side by side while they're compared, and only then do we cut over.

Direct communication

You talk to the people who design and build. No unnecessary layers of management, no intermediaries.

Process

Four stages,
none of them blind.

Assessment

Inventory, dependencies and business rules. We come out with a modernization roadmap and an estimate, not a closed proposal.

Data in parallel

A replica with integrity verified against the original. Both systems run side by side while they're compared. Nothing is switched off.

Interoperability

APIs that expose what the old system knows how to do, without touching its internals. From there the new is built against a stable interface.

Modern surface

The new interface comes last, on data that is already trustworthy. Users see the change once everything underneath is settled.

Contact

You don't need a migration
already scoped.

If you have a system where you recognize any of these signs, we can start by understanding it:

Every change costs more than the last one
You depend on two or three people who know how it works
You can't integrate new products on top of it
It still runs processes that cannot fail
It can't be switched off to replace it

A first technical conversation. No off-the-shelf sales pitch.