Accelerate and Automate Migrations

Migrations fail slowly. The plan is sound, the first modules go well, and then the work outlasts the team’s attention: people rotate, the source system keeps changing under the migration, and eighteen months in nobody can say which of the four hundred modules is verified, which is translated but untested, and which was quietly skipped. A migration is not a project with a beginning and an end. It is a factory that has to run, at the same quality, for as long as it takes.

Lightspeed runs that factory as a fleet of agents that do not rotate, do not forget, and do not stop when a worker restarts.

The factory

A planner session owns the migration. It reads the map of the estate, the output of mapping the legacy systems, and breaks it into slices: a batch chain, a service, a schema domain. For each slice it spawns builders, testers and reviewers from profiles the bank approved. Each sub-agent gets a clean machine provisioned from one versioned image, clones the repositories, translates or rewrites its part, runs the existing test suite and the new one, and hands its result back. A reviewer sub-agent critiques the builder’s work with fresh context, and the planner decides whether the slice is done. Machines are released when the slice closes; the fleet is bounded by limits on depth, descendants and concurrency the planner cannot exceed.

The fleet survives everything a long project throws at it. A worker restart, a redeploy of Lightspeed itself, a weekend: the sessions are durable workflows and pick up at the next step. Idle sessions cost nothing, so a migration can pause for a change freeze and resume without anyone re-briefing anyone.

Two strategies from one state

Migration decisions are expensive to reverse: strangler pattern or big bang for this module, rewrite or transpile, keep the batch window or go event-driven. Lightspeed lets the factory try both. A session can be forked at any point, and the fork carries the complete state, straight from the event log, without replaying the work that got there and without paying for the shared context twice. Run the two strategies as two branches on two machines, compare the test results and the reviewer’s verdicts, keep the winner. The losing branch is closed and its machine released; its log remains as the record of why it lost.

Verified, not believed

Every slice is gated by tests, and the agents themselves are gated by tests. Lightspeed’s eval harness regression-tests agent and tool workflows, so when the bank changes the translation prompt or upgrades the model halfway through, the change is proved against the slices already done before it is allowed near the ones remaining. The deterministic core makes the comparison exact: the same inputs replay to the same decisions, so a differing decision is a real difference.

The bank’s workflow drives it

The migration does not run in a tool beside the bank’s process; it runs inside it. The bank’s own Temporal workflow starts each slice as a managed session, binds its activities as the agent’s tools, sets the deadline, and receives durable emissions back: slice translated, tests green, reviewer approved. Approval gates are the workflow’s own signals. If a human must sign off a slice and does not within the window, the session is cancelled cleanly and the slice returns to the queue. The programme office sees the migration as a workflow with agent steps, because that is what it is.

For the reviewer and the regulator

Every decision the factory made is in the event log: which module, which strategy, which tests ran, what the reviewer said, who approved. When a regulator asks how the bank assured a migration that touched the ledger, the answer is a replayable record per slice, not a status deck.

Arithmetic

Four hundred modules, an average of two builder-tester-reviewer cycles per module, four machine-hours per cycle: 3,200 machine-hours of borrowed compute, spent only while the work runs, at whatever the bank’s own compute costs. The planner and the four hundred slice sessions between them are rows in an event store while they wait. The cost of the migration is the cost of the work, not the cost of keeping four hundred environments alive for a year and a half.

Rests on: sub-agents, per-session environments, session fork and clone, the eval harness, managed sessions, the generic workflow-tool protocol, deadlines and cancellation, auditable by design.