Run old and new accounting systems in parallel safely

A parallel run compares a defined set of accounting activity or outputs in the old and proposed systems. State the questions it must answer: whether transactions are complete, mappings work, recurring calculations behave as expected, and users can produce the required reports.

Do not begin by asking staff to maintain two full production ledgers indefinitely. That can create duplicate work, competing balances, and confusion about which system is used for actual business actions. Choose one authoritative operational record and define the other system's testing role.

Intuit explicitly says that QuickBooks Desktop and QuickBooks Online do not continue synchronizing after a move. Other products and integrations have their own behavior. Verify the actual connection rather than assuming that entering a correction in one system automatically updates the other.

Write the start, covered period, transaction population, responsible team, and expected end of the comparison. A test without an exit condition can become a permanent second bookkeeping process.

Identify every action the proposed system can send outside the test: payment requests, customer invoices, collection reminders, payroll instructions, filings, or messages through connected applications. Have the technical and accounting owners confirm which are disabled or directed to a safe test route.

A test ledger should not accidentally become a second payment operator. Users need clear labels, appropriate access, and instructions about where live work belongs. If a process cannot be isolated safely, design a different test with the responsible implementation team.

Microsoft's test-planning guidance links tests to expected outcomes, controlled solution versions, and suitable environments. Apply that principle to the accounting comparison. Keep the source population and configuration identifiable so a difference can be investigated without guessing which version someone used.

Plan how sensitive records are handled in the test environment. Use the access and data-protection arrangements appropriate to the actual information. An operational rehearsal does not justify giving every tester unrestricted access to payroll or owner records.

Use a defined source extract or controlled transaction list. Record the relevant entity, period, currency, accounting basis, and report filters. Confirm that both systems contain the intended population before comparing totals.

Keep a difference register with the amount, affected report or account, cause, owner, and evidence of resolution. Separate missing transactions from mapping differences, timing, configuration, calculation rules, and known presentation changes. A single unexplained variance figure is not a useful investigation plan.

For an illustrative example, the old system shows 120 supplier invoices while the test system shows 119. Investigate the missing record before using a balancing journal to make the payable totals match. A matching total can conceal a missing invoice and another offsetting error.

Assign the correction to the right owner: data preparation, configuration, accounting policy, or software behavior. Record the approved change and rerun the affected comparison. Keep enough evidence to show that the change resolved the original issue without introducing another one.

If the test population changes, say so. A result based on yesterday's source extract cannot be directly compared with a ledger that includes today's late entries. Either freeze the defined population or maintain an explicit list of subsequent activity and corrections.

Review important exceptions with a competent accounting person. Some differences are expected and explainable; others prevent reliance on the result. An accepted difference needs a reason and owner, not just a note that the implementation team considers it small.

Include the users who will prepare and review the work after launch. A technical import can succeed while the accounting team cannot retrieve support or produce the required report. That operational evidence is part of what the run should establish.

Set exit criteria before reviewing the final results. Define the important outputs that must reconcile, the defects that prevent acceptance, and the treatment of any permitted residual issues. Avoid a universal percentage threshold that could allow a serious exception to pass.

Confirm who signs off the comparison and what that approval means for the migration decision. Keep the final source version, target version, comparisons, resolved issues, and remaining limitations together.

At the operational switch, communicate the authoritative system and stop unnecessary duplicate entry. Preserve the old records through the agreed access and retention arrangement. A successful parallel run should remove uncertainty and allow a clear transition, not leave two competing versions of the company's books.