Data-Only Migration: What Happens to In-Flight Loans When You Switch LOS

What happens to every in-flight loan on the day you switch LOS? The answer to that question is where most migrations die.

Every lender running a legacy origination system has priced a replacement at least once. The platform evaluation goes well, the business case holds, and then someone asks about the applications currently in progress: the half-complete files, the deviations mid-approval, the disbursements pending documentation. The conventional answer is to migrate them, which means mapping every live case, in whatever state it happens to be, into the new system's data model, and trusting that two different state machines agree about what "pending legal opinion" means. The project plan for that mapping is where the enthusiasm goes to die, because everyone in the room knows what one mismapped case is: a customer whose loan is stuck between two systems, and an operations team that trusts neither.

The way out is to refuse the premise. Live workflows do not need to be migrated. They need to be allowed to finish.

The Core Principle

Data-only migration rests on one rule: never move a live workflow. Only completed cases move, and they move as read-only historical archives. New applications start exclusively on the new system from cutover day. In-flight cases stay on the legacy system, running on the workflows and logic they started with, until each reaches its natural end state.

No case is ever translated mid-decision. The riskiest object in the whole migration, the half-finished application, is precisely the object that never crosses systems.

The Timeline, Phase by Phase

**Before cutover.** All cases that have already reached an end state, approved, rejected, cancelled, or withdrawn, are exported from the legacy system and loaded into the new platform as searchable, read-only archives.

**Cutover day.** Every new application originates on the new LOS. The legacy system takes no new work from this day. Its only remaining job is to finish what it started.

**The 90-day parallel run.** In-flight cases complete naturally on the legacy system. As they close, rolling export cycles move the newly completed cases into the archive, a progressive drain rather than a last-minute rush. The 90-day window is sized against reality: the average loan lifecycle in a legacy system runs about 45 days, so 90 days gives every pre-cutover case a comfortable buffer to finish.

**After the window.** The legacy system is decommissioned. The handful of residual outliers, cases that somehow outlived the window, are handled through a defined exception plan rather than an improvised scramble.

Why the Archive Design Matters

The second fear in every migration, after the in-flight cases, is the history. Regulators and credit teams need years of past decisions available, and re-modelling that history into a new schema is its own multi-month mapping project with its own error surface.

Data-only migration skips it. Historical records come across as archival files with a thin metadata index, accessible from inside the new LOS and searchable by legacy application ID, customer identifiers, dates, and end state. An officer looking up a past borrower finds the file; a compliance team answering a lookback request finds the population. The history arrives as history, in its own words, rather than reinterpreted into a new data model that did not exist when the decisions were made.

What the Approach Removes

Three project workstreams simply do not exist in this model. There is no live-state mapping, because live states never move. There is no schema translation of historical data, because archives carry their original form. And there is no big-bang weekend, because the parallel run makes cutover a calendar date rather than a cliff.

What remains is a clean end state: one platform originating and processing all new work, the same platform answering every historical lookup, and a legacy system that switched off after 90 days because there was nothing left for it to do. This is the approach we developed and ran in a live LOS replacement at a multinational bank, and it is now how we treat every legacy exit: the migration project should be the least dramatic part of the platform decision.