cutover

A cutover is the moment when you stop running an old system and start running a new one in its place. In telephone switchboards, this meant physically unplugging cables from the old switch frame and plugging them into the new one, often in a single coordinated operation lasting minutes or hours. The goal is to move traffic from the old equipment to the new with minimum disruption or dropped calls.

Cutover strategy depends on whether the old and new systems can run in parallel. With a telephone switchboard, you could route calls through both machines temporarily, with duplicate line cards and relay circuits handling the same incoming trunks. Once traffic had settled and operators confirmed everything was working, technicians would disconnect the old frame entirely. This parallel cutover reduces risk but requires extra hardware and wiring during transition.

The alternative is a flash cutover, where you switch instantaneously without parallel running. This saves money and avoids the mess of maintaining two live systems, but any unforeseen problem hits all customers at once. A single wrong jumper cable or failed relay contact could black out an entire exchange. Old telephone companies often chose the slower parallel approach; modern data centers doing server migrations face the same trade-off.

Cutover success depends on preparation. Before the switch, technicians verify that all circuits and line assignments match between old and new equipment. Call records, billing tables, and customer feature settings must be transferred or re-entered correctly. A cutover was often scheduled for low-traffic hours, typically Sunday night or early morning, to minimize the impact of unforeseen failures. Supervisory staff would remain on duty to handle complaints and manual overrides.

The term has grown beyond telephony. Today you hear it applied to any system migration: switching from one database platform to another, moving a factory from one ERP system to the next, or transitioning a power grid section to new control hardware. The principle stays the same: duplicate the setup, test it thoroughly in parallel if possible, then disconnect the old system once you are confident the new one is handling the load.