Enterprise / Migration
Migration
Leaving an estate you are afraid to touch.
Renewal economics change, vendors get acquired, and roadmaps quietly stop. None of that makes the nightly batch less load-bearing — which is why most of these migrations are announced, scoped, and then abandoned at the risk review. The blocker is not the work; it is the inability to prove the replacement is safe. That is the part we make tractable.
Why these programs actually stall
- The graph lives in people, not files. The authors retired. What survives is a definition file, a run history, and three operators who know which jobs to force-start at 3 a.m.
- Testing cannot cover the real thing. Non-production runs do not reproduce month-end, the holiday calendar, the day the feed arrives late, or the night recon fails. The scenarios you fear most are the ones you cannot stage.
- Nobody can sign the memo. Migration decks argue by assertion — "functionally equivalent" — and the control function is right to refuse an assertion.
Replay attacks all three at once. Your recorded history is the test corpus: month-end is in there, so is the holiday, so is the bad night. The proof reconstructs the graph as the model sees it and shows exactly where reality disagreed — including the undocumented force-start, which surfaces as a containment break rather than as tribal knowledge.
What we need, per platform
| Platform | Definitions | Run history | Coverage today |
|---|---|---|---|
| AutoSys | autorep -J PREFIX% -q (JIL text) |
Reporting export with job, date, status; start/end times if available | Job chains via success() / done() conditions; human gates inferred from naming. Shorthand predicates and box grouping in progress. |
| Control-M | DEFTABLE XML export | Reporting export; Ended OK / Not OK understood |
Jobs and their condition-based dependencies across the table. |
| IBM BAW | .twx archive |
Case-system event log (CSV), where one exists | Process definitions and task structure; discovery from event logs where the model is thin. |
| Pega | Application export | Case event log (CSV) | Asset detection and discovery-led mining; deep rule extraction is not claimed. |
| cron | crontab files | Wherever your wrapper logs land | Independent scheduled jobs — no dependency graph to prove, but they inventory. |
Everything above is an export. We never need production access, credentials, or a network path into your scheduler — and the tooling has no network I/O to use one with.
The sequence that survives a risk review
| Step | What you do | What you can say afterward |
|---|---|---|
| 1 | Scan the estate | "Here is what we run, which parts are deterministic, and where humans are actually in the loop." |
| 2 | Prove one chain against 10–30 days of history | "For this chain, the replacement makes identical decisions across every recorded day, including the failure night." |
| 3 | Investigate divergences | "We found two undocumented behaviours before cutover, not during it." |
| 4 | Move that chain; keep proving in parallel | "The old and new agree, day after day, on live history." |
| 5 | Repeat by chain, not by big bang | "Each wave carries its own evidence bundle." |
Note what step 2 does to the negotiation as well as to the risk: a chain you have proven can move is a chain whose renewal you are no longer forced to accept at any price.
Honest limits
- We do not rewrite your jobs. The scripts and programs that do the work are yours and keep doing the work. What moves is the orchestration — the decisions about what runs when, under which conditions, with which gates.
- A proof is not a cutover. It is the evidence that justifies scheduling one.
- Coverage is honest, not aspirational. If your estate leans on a construct we parse thinly, the proof reports a coverage gap and refuses to pass. Ask us before the pilot and we will tell you where the edges are this month.
Start with one chain
Pick the batch chain that scares you most. That is the one worth proving first — and the one whose proof makes every subsequent conversation easier.