Skip to content
Balkan Tecnologia
AccessibilityGet in touch
Balkan Tecnologia

Replacing a legacy system one part at a time

We replace the legacy system one function at a time: the new part takes over a piece, the old one runs the rest until it can be switched off.

A mint-green thread linking three blank cards like a system plan, beside a brass compass.

Who it's for

For companies that depend on an old system to operate and cannot stop to replace it.

What it solves

  • The system has run invoicing for years, but only one person knows how to change it.
  • Every release is a risk, so the team avoids changing anything.
  • The language and database are so old that it is hard to hire anyone who knows them.
  • A full rewrite has already been tried and stalled halfway.
  • Connecting to Pix, APIs or new systems takes bigger and bigger workarounds.

What we do

Map of the current system
Functions, dependencies, integrations and data in the legacy system, including what nobody documented.
Replacement order
Which parts go first, based on the value and risk of each one.
A layer in front
A single entry point that decides whether each call goes to the new system or the old one.
Data on both sides
Synchronisation between the old and the new database while both systems run side by side.
Comparing results
The new system runs in parallel and both sets of answers are compared before each switch.
A way back at every step
Each part can return to the old system if something goes wrong at the switch.
Switching off the legacy
When the last function moves out, the old system is shut down and its data archived.

What you get

  • A map of the legacy system: functions, dependencies, integrations and data
  • A piece-by-piece replacement plan, with the order and criteria for each switch
  • A routing layer and data synchronisation between old and new
  • Each new part in production, with tests and monitoring
  • A rollback procedure for every switch

How we do it

  1. Mapping

    Reading the code, data and integrations, and talking to the system's users.

  2. First piece

    We pick a low-risk function to prove the approach.

  3. Running side by side

    New and old systems running together, with the data kept in sync.

  4. Successive switches

    One part at a time, each with comparison, monitoring and a way back.

  5. Switch-off

    The legacy system is retired once no function is left in it.

Technology examples

  • NGINX
  • Debezium
  • PostgreSQL
  • RabbitMQ
  • Docker
  • OpenTelemetry

Related services

FAQ

Isn't it faster to rewrite everything at once?

It looks that way, but a full rewrite only delivers value at the end and puts all the risk on a single switch. Done piece by piece, each step reaches production and can be rolled back.

How long does it take?

It depends on the size of the legacy system, how many integrations it has and the quality of its data. The initial mapping is what makes a serious estimate possible.

Do operations stop during the change?

The aim is that they do not. Switches are planned for quieter hours, and each one has a way back.

What happens to the old system's data?

It moves along with each part, checked between old and new. When the volume is large, that becomes a data migration project of its own.

Write to Balkan

Talk to us about your project