Skip to content
Balkan Tecnologia
AccessibilityGet in touch
Balkan Tecnologia

Data in the new system, checked before the switch

We move data from the old system to the new one with written conversion rules, full dry runs before the switch, reconciled totals and a way back.

A mint-green thread wound on three wooden bobbins, running from one to the next.

Who it's for

For companies switching ERP, platform or database that cannot afford to lose their history.

What it solves

  • The new system is ready, but nobody knows whether the old data will arrive intact.
  • There are duplicate customers, invalid CPFs and fields used for something else over the years.
  • The last migration was done with spreadsheets and left balances that still do not match.
  • The switch has a date, but there has never been a full dry run.
  • If something goes wrong on the day, there is no way back to the old system.

What we do

Data profile
Volumes, empty fields, duplicates and non-standard formats surveyed before any rule is written.
Conversion map
Each old field linked to the new one, with the conversion rule written down and approved by your team.
Clean-up
Duplicates and invalid data fixed by rule, or set aside for someone who knows the business to decide.
Migration dry runs
The full migration runs in staging as many times as needed, measuring time and errors.
Reconciliation
Counts, totals and balances compared between old and new, record by record when needed.
Two-stage load
With large volumes, history moves first and only the difference goes in on switch day.
Switch and rollback plan
The day's script, who does what, and how to return to the old system if reconciliation fails.

What you get

  • A data profile report, with the problems found
  • A field-by-field conversion map, approved by your team
  • Versioned migration scripts that can be run again
  • A reconciliation report for every dry run and for the final migration
  • A switch-over runbook with a rollback plan

How we do it

  1. Survey

    Source, target, volumes and what needs to come across: all history or only part of it.

  2. Map and rules

    Field by field, with clean-up decisions made by your team.

  3. Dry runs

    Full migrations in staging, until every difference in the reconciliation is explained.

  4. Switch

    Final migration in the agreed window, reconciled before the system is released.

  5. After the switch

    Follow-up in the first days, with the old system still available for lookups.

Technology examples

  • PostgreSQL
  • SQL Server
  • Oracle
  • Python
  • pgloader
  • Debezium

Related services

FAQ

How long is the system down during the switch?

It depends on the volume and how much can move in advance. A two-stage load shortens the window, but there is usually a period with no new entries; the dry runs measure it, and the date is set around it.

Do we need to migrate all the history?

Not always. Sometimes the new system receives only open items and the history stays in a read-only database. It depends on how the data is used and on record-keeping obligations, which your accountant or legal team defines.

Who decides what to do with bad data?

Your team. We list the cases and propose rules; anything that needs business knowledge, such as which of two duplicate records is the right one, goes to a person to decide.

What if the new system's vendor already handles the import?

All the better. We then prepare the data in the format they ask for and handle the reconciliation between old and new, which someone has to own.

Write to Balkan

Talk to us about your project