Replacing a Business System: When Does Running Both Systems Help?

Keeping an old business system available during replacement can help compare results or move work in manageable stages. Before approving that period, require four things: a specific purpose, a clear authoritative record, someone responsible for investigating differences, and an agreed test for ending it.

For a CEO, operations owner or finance director, the decision concerns how the business keeps accurate records and completes daily work. “We will run both” leaves too much unresolved. The proposal needs to explain what each system will do, what staff will use and what the temporary arrangement costs.

Three different meanings of running both

Comparing outputs. One system continues to perform the live business action while the replacement calculates a result for comparison. In a hypothetical accounting replacement, the team could compare reports for the same defined period and inputs while the existing system remains responsible for issuing invoices. Comparing calculations must not accidentally send a second invoice, payment, order or email.

Agree which differences matter and who investigates them. A matching total may conceal different individual records, rounding rules or timing. Successful data copying also leaves a separate question: can staff complete the required workflow, including corrections and exceptions?

Moving responsibility in phases. A defined function or customer group moves to the replacement while other work stays in the old system. Each stage needs a clear instruction about where staff enter changes and where reports obtain their records. Keeping both applications available does not give both authority over every record.

Microsoft's Strangler Fig guidance describes gradually moving functionality and eventually removing the old system. Dependencies and shared data need attention throughout. For a business owner, the useful question is whether responsibility can be divided clearly enough to operate and check each stage.

Deliberately writing to both systems. Here, software is expressly designed to record changes in two places. This creates another obligation: explain what happens when one write succeeds and the other fails. Someone must detect the difference, decide which record governs and complete or correct the missing work.

Ed Murray's 2020 AWS practitioner explanation of migration rollback illustrates the coordination involved in dual writes and staged fallback. It is a dated technical example, not a ready-made implementation plan. Manual duplicate entry or a promise of synchronization does not settle these responsibilities.

Compare coexistence with a rehearsed single cutover

Phasing can limit how much work changes at once, but maintaining two operating environments adds support, training, reconciliation and temporary integration work. Include those costs in the replacement decision, together with the cost of removing the temporary connections.

In their 2022 article Transitional Architecture, Ian Cartwright, Rob Horn and James Lewis describe temporary bridges and their eventual removal. Their experience explains why a bridge can serve a useful purpose while still needing its own budget and exit.

A rehearsed single cutover deserves comparison when the system is small, responsibility cannot be divided, suitable integration points are unavailable or an urgent retirement deadline rules out prolonged coexistence. Microsoft identifies similar suitability limits for gradual replacement. These conditions do not make a single cutover automatically safe. They make its preparation, operational checks and decision authority especially important.

Ask for evidence from a rehearsal of the proposed transition and agreed conditions for proceeding or stopping. Compare the two options against the actual work that must continue. Neither arrangement has a universal duration or acceptance threshold.

New transactions change the reversal decision

Once people have entered valid work in the replacement, reopening the old application can leave those newer records behind. Orders may also have triggered deliveries, payments or messages that cannot be undone by restoring a database.

AWS cutover guidance distinguishes reversal before new data from reversal after new transactions, when the original database may be stale. Before approving fallback, require a specific treatment of new records and their downstream actions. A backup alone does not establish that operations can resume coherently.

The decision record to request

A short record should let the people running the business answer these questions:

• Purpose and scope: Which work is being compared or moved, and what does keeping both systems achieve?
• Authority: Where are changes entered at each stage, and which records govern affected reports and actions?
• Reconciliation: Who investigates differences, how are they recorded, and who resolves disputed results?
• Acceptance: What evidence permits the next stage, what stops it, and who makes the go/no-go decision?
• Reversal: How will new transactions and completed downstream actions be handled if work returns to the old system?
• Exit: What evidence permits retirement, who removes temporary bridges, and what records must remain accessible under the applicable requirements?

Approve coexistence when its purpose and operating responsibilities justify its cost, with an achievable exit. If you are assessing a replacement, our legacy system replacement service is a place to discuss the current system, the work that must continue and the constraints on changing it.