Yes, but not by cutting over. The technique is to run both ledgers in parallel against live traffic, with the old one authoritative, and to compare every posting until the new one has demonstrated it produces identical results for a sustained period. The migration completes when authority moves, which is a configuration change, not an event. And by then the risky work has already been done in daylight with a working fallback.
A cutover weekend concentrates all the risk into the hours when you have the least ability to diagnose anything and no way back. Dual-running inverts that: the new system is wrong in production for weeks, safely, while nobody depends on it, and every discrepancy is a bug found under normal conditions rather than at 3am against a deadline.
The hard part is the comparison, not the writing. Two ledgers will disagree in ways that are legitimate, such as rounding, timing and ordering under concurrency, and a migration team that cannot distinguish a legitimate difference from a real defect will either chase noise or, worse, learn to ignore the alerts. Defining what "identical" means, precisely, is the first deliverable, not an afterthought.
Balance migration is the part people underestimate. Opening balances in the new ledger must be derived from the old system's movement history, not asserted from its current balances, or the new ledger begins its life with numbers it cannot explain. Where history is missing, that gap is documented explicitly rather than papered over.
The approach requires the rest of the system to talk to an interface you own, not the vendor's SDK. If every service calls the incumbent directly, there is nowhere to insert the second ledger, and dual-running is not available at any price. That single decision, usually made years earlier, determines whether a zero-downtime migration is possible at all.