Batch job conversion

The second project type. Where web application modernization is organised around features and screens, batch job conversion is organised around jobs and the data they move — scheduled or triggered programs that read and write a legacy database.

The shape of the work

Discovery builds an inventory of the legacy batch estate. Each job is recorded with what it is and how it runs: its entry point, its scheduler trigger, the command that executes it, the data stores it reads and writes, its source files, and how often it runs.

That inventory is the as-is. As with the web application flow, it is a record of what exists, and it is the thing to review before anything is converted.

Schema conversion takes the legacy database schema and produces the modern one. The source schema is extracted, the target schema is deployed, and a conversion report records the mappings it made and the warnings it raised. Read the warnings: a mapping the conversion was unsure about is where a silent data problem starts.

The Batch Catalog is the to-be counterpart of the discovered inventory — the jobs as they will exist on the modern target.

Conversion produces the modern job.

How a converted job is verified

This is the part worth understanding, because it is stronger than reading the code:

• Containers are set up for both the source and the target — the legacy job and its replacement, each able to run.
• Test code is generated for the job.
• A baseline validation runs the legacy job and records what it does.
• A target validation runs the converted job.

The comparison between those two runs is the evidence. A converted batch job is not accepted because it looks equivalent; it is accepted because it did the same thing to the same data.

What is shared with the other project type

Jobs, Agent Logs, settings, the web IDE, costs and the CLI work the same way. The differences are concentrated in the discovery, catalog and validation surfaces described above.