Migration · methodology

Three closed months, or we do not cut over

Every migration page on this site repeats the same rule, so it deserves its own explanation. We do not retire your existing system until a shadow ledger has tied to its trial balance across three consecutive closed months — not a spot check, not one clean month, three full closes where the numbers agreed without anyone intervening.

Start read-only

Connect your current system read-only and watch it reconcile. Stop at any point having lost nothing.

1 / 3
Three closes, not oneCutover follows evidence, not a dateWe have delayed cutovers over this
Their QuickBooksas filed
1000 · Cash412,880.14
1200 · Accounts receivable286,401.00
2010 · Accounts payable(94,220.55)
4000 · Revenue(1,842,110.00)
6000 · Operating expense1,237,049.41
Trial balance0.00
erp.io shadow ledgercomputed
1000 · Cash412,880.14
1200 · Accounts receivable286,401.00
2010 · Accounts payable(94,220.55)
4000 · Revenue(1,842,110.00)
6000 · Operating expense1,237,049.41
Trial balance0.00

184 consecutive days tied · variance $0.00

Every night, both directions. A difference raises an exception with the underlying transactions attached rather than being absorbed.

What is actually checked

Six comparisons, run nightly.

A migration that only compares closing balances can be wrong in several ways that produce a matching total. These are the checks that catch those.

Trial balance, every account

Total debits, total credits, and closing balance per account compared between your system and the shadow ledger. Not a sample — every account, every night.

Subledger to control account

AR, AP, inventory, and fixed assets each tie to their control account independently. A trial balance can agree while a subledger underneath it does not.

Transaction counts and totals

Counts by type and period alongside value totals, because two errors of equal size in opposite directions produce a matching balance and a wrong ledger.

Point-in-time reconstruction

The shadow ledger must reproduce what your books looked like on a past date, not just what they look like now. That is what tests the history rather than the current state.

Movement, not just balance

Opening balance, movement, closing balance per account per period. A rollforward that ties is meaningfully stronger evidence than a closing balance that does.

Exceptions raised, never absorbed

Any difference produces an alert with the transactions attached. Nothing is written off to a rounding account and nothing is plugged.

Permitted

  • Adjusting entries
  • Reclassifications

Blocked

  • New subledger activity
State is enforced by the posting engine, not by convention. An agent cannot post into a closed period at any authority level.

A month counts toward the three only once it is closed in your existing system. An open period that agrees proves considerably less.

Why one clean month is not evidence

A single month can agree by construction. If the shadow ledger was built by copying balances rather than by reprocessing transactions, the first comparison is a tautology — you have compared a number to itself and learned nothing.

Three consecutive closed months forces the shadow ledger to handle a full cycle of real events: accruals reversing, prepaids amortising, intercompany matching, revenue schedules advancing, and at least one period-end adjustment somebody posted late. Those are where migrations are actually wrong.

A migration whose first reconciliation is clean has usually not reconciled properly. It has compared a number to a copy of itself.

The seasonality argument

Three is a compromise. Twelve months would test annual events — the audit adjustment, the bonus accrual, the year-end revaluation — and nobody would run a parallel system for a year to find out.

Three catches the monthly cycle reliably and misses genuinely annual behaviour. We say that plainly rather than implying the rule is exhaustive, and where a customer has unusual quarterly events we extend rather than pretending three covers it.

Closed, specifically

A month counts only once it is closed in your existing system. An open period agreeing proves much less, because the entries that most often diverge — accruals, reclassifications, and late adjustments — arrive during the close rather than during the month.

In practice this means the three months are three closes, which for a team closing in fourteen days is a longer calendar period than the number suggests. That is understood when we plan it.

What happens when it does not tie

It frequently does not, at first. The differences we find fall into four categories and each is handled differently.

  • The shadow ledger is wrong. A mapping error, a mishandled transaction type, a rounding convention. We fix it and the three-month clock restarts.
  • The source system is wrong. More common than customers expect. An unbalanced period, a duplicate posting, a journal that hit a suspense account. We report it and you decide how to handle prior periods.
  • Both are right and the rule differs. Two defensible readings of the same treatment. This is a decision for your controller, and we record which reading was chosen and why.
  • Timing. A transaction that landed in different periods on the two sides. Usually resolves itself by the following close and is worth watching rather than fixing.
We have delayed cutovers over this and would again

On several engagements the three-month clock has restarted twice, pushing a planned cutover by a quarter. That is an uncomfortable conversation and it is a better one than the alternative, which is discovering the problem after the old system has been retired and the evidence is gone.

What this rule costs us

Revenue timing, mostly. A migration that could nominally complete in six weeks takes four to five months to reach retirement, and we cannot recognise it as complete until it is. It also means occasionally telling a customer their data has problems we did not create.

We think it is the right trade. Every finance system migration is a bet that the new numbers are right, and the three-month rule is the only mechanism we have found that settles the bet before the evidence is destroyed.

Questions

Common follow-ups.

Can we cut over sooner if we accept the risk?
We would rather not, and we have declined. The rule exists because the evidence disappears when the old system is retired, and a customer accepting that risk in month two is accepting it without the information that would make it an informed choice.
What if our books have a pre-existing error?
The reconciliation finds it and we report it. It is more common than customers expect, and how prior periods are handled is your decision with your auditors, not ours.
Does the clock restart for every difference?
For material ones, yes. Timing differences that resolve themselves by the next close are watched rather than treated as failures, and the distinction is recorded.
Why not twelve months?
Because nobody would run parallel for a year, and we would rather state the limitation than pretend three months tests annual events. Where a customer has unusual quarterly behaviour we extend.
What does the parallel period cost us?
Your existing licence continues during it, which is a real cost. We factor that into the recommendation, and it is one reason we suggest integration first for customers whose problem is reporting rather than the ledger.

Start read-only and watch it tie.

Connect your current system, let the shadow ledger reconcile nightly, and decide about migrating later.