Migration & modernization

Most migration projects we see started as a two-year plan and are still running. The legacy platform keeps running too, and the company pays for both. The reasons are rarely technical:

• -Nobody knows exactly what runs on the old platform, who uses it and what can be switched off.
• -The plan moves everything at once, so nothing is finished until everything is.
• -Business rules are buried in stored procedures and ETL jobs that nobody wrote down.
• -Converted code is not checked against the old results, so trust in the new platform takes months to build.

• Workload by workload, not a big bang. Each workload is migrated, checked and switched off on the old platform before the next one starts.
• The target is chosen, not copied. We propose a few architecture scenarios on an open, modular stack and you pick one on its latency, cost and effort, instead of rebuilding the old platform on new services.
• Inventory first. We map what runs, what it reads and writes, and who uses the outputs, and a good part of it can usually be switched off without migrating.
• Agents do the repetitive part. Code conversion, documentation of the existing logic and the first version of the tests are done with coding agents, and engineers review every change.
• Same results or no switch. Each migrated workload is compared with the old one on real data before users move.

1. 01

   Inventory & dependency map

   Jobs, procedures, tables, schedules and the reports that depend on them, extracted from the platform itself, not from interviews only. Each workload gets a status: migrate, rewrite or retire.

2. 02

   Target architecture scenarios

   The target is an open, modular data stack: transformations as code with tools like dbt, open table formats, a cloud data warehouse or lakehouse for analytics, and streaming where the business needs data within seconds. Each component can be replaced without rebuilding the rest. We propose two or three scenarios, each costed and placed on latency (batch, near real time, streaming), run cost and migration effort, so the choice is made per workload.

3. 03

   Business rules extraction

   Agents read the legacy code (SQL, PL/SQL, ETL definitions, Spark or Hadoop jobs) and write down the business rules it applies, so they can be validated with the business before anything is rewritten.

4. 04

   Conversion

   The code is converted to the chosen target with coding agents, using the conventions and templates we set first, then reviewed by engineers.

5. 05

   Reconciliation

   Old and new outputs are compared automatically on the same data: row counts, aggregates and row-level differences, until they match or each gap is explained.

6. 06

   Switch & decommission

   Users move, the old workload is switched off, and its cost leaves the bill. Then the next workload.

• -A 2-hour discovery on your legacy platform and the target you have in mind.
• -An inventory, two or three costed architecture scenarios, and a migration plan workload by workload, with the ones to retire.
• -A first workload migrated, reconciled and switched off, to measure the pace for the others.