Data Platform Migration Without Source Code

What is source code, and why does it matter?

Source code is the human-readable set of instructions behind an application. When migrating a data platform, engineers read it to understand which records are selected, how values are calculated and where the data goes. With source code available, that logic can be studied and rebuilt in SQL, PySpark or a modern pipeline.

Sometimes only the compiled software remains: a DLL, executable or proprietary application. It still runs, but its original instructions and documentation are gone. That is a common problem in older ETL and reporting estates.

Why this used to block migrations — and what changed

Reverse engineering compiled programs has been possible for decades. The obstacle was the cost: understanding a large, undocumented executable could require specialist analysts and weeks of manual tracing. Teams often retained the old application because replacing it carried too much uncertainty.

Decompilers have improved, and tools such as Ghidra, publicly released in 2019, made powerful binary analysis widely accessible. More recently, REA (Reverse Engineer Anything) has made it possible to connect those analysis tools to coding agents, so investigators can systematically trace functions, dependencies and evidence.

These tools do not restore lost source code perfectly. They make it more practical to recover enough of the behaviour to build and test a replacement.

Four situations where this helps

1. SSIS packages with custom DLLs

An SSIS package calls a custom .NET library to calculate discounts, taxes or other values. The package is available, but the DLL's source code is not. We can inspect the assembly, investigate the calculations and rebuild them in Spark SQL or PySpark for Microsoft Fabric or Databricks.

2. Undocumented nightly batch jobs

An executable runs every night, queries a database and produces reporting files. Nobody knows precisely which records it excludes or how it handles dates and currency. Analysing the executable and running controlled comparisons can help reconstruct the selection and transformation rules before replacing it with a pipeline.

3. Legacy ERP data exports

An old ERP application generates exports through undocumented screens, interfaces or internal routines. Investigating its available application components and observed data exchanges can reveal export parameters, formats and processing steps, giving engineers a starting point for a supported replacement integration.

4. Proprietary data files

An industrial or laboratory system writes binary files readable only by its original application. By examining the software that reads these files, engineers can work out record layouts and conversions, then build an ingestion process that outputs Parquet or Delta.

From investigation to a working migration

The practical sequence is straightforward:

1. Locate what remains: packages, DLLs, executables, configuration, sample inputs and outputs.
2. Recover the behaviour: trace relevant functions, data fields, filters and dependencies using software-analysis tools.
3. Rebuild what is needed: implement the recovered rules in maintainable SQL, PySpark or pipeline components.
4. Test against the old system: compare outputs, investigate mismatches and document what cannot yet be verified.

Some components are too obfuscated, incomplete or dependent on inaccessible systems to reconstruct confidently. That uncertainty is part of the assessment, not something to hide.

Missing source code is a migration risk. It no longer has to be an automatic reason to keep the old platform running.