Customers

What migrations actually took

Including the ones that took longer than planned, the ones where the reconciliation clock restarted twice, and the substantial share that never became migrations at all because integration solved the problem.

Considering a migration?

Tell us your source system and entity count. We will give a realistic timeline, not a planned one.

1 / 3
Actual elapsed, not plannedClock restarts countedMost never migrated

Customers

Elapsed time by source system.

Time to cutover, then the parallel period after it. Both measured as actually elapsed rather than as originally planned.

QuickBooks Online

Median 3 weeks to cutover, 8 weeks parallel. The most straightforward source we work with — good API, clean extraction, and the work is in dimension mapping rather than in getting data out.

QuickBooks Desktop

Median 7 weeks to cutover, 10 weeks parallel. Roughly three times the Online figure, and most of the difference is list cleanup rather than extraction.

Xero

Median 3 weeks to cutover, 8 weeks parallel. Extraction is easy; remapping two tracking categories into real dimensions across history is the work.

Sage Intacct

Median 5 weeks to cutover, 9 weeks parallel. Dimensions transfer cleanly, which is unusual. Report parity is the part customers underestimate.

NetSuite

Median 8 weeks to cutover, 12 weeks parallel. SuiteScript customisation is the variable, and where it is substantial we have advised customers not to move.

Legacy and on-premise

Median 14 weeks to cutover, 14 weeks parallel. These run through our legacy replacement methodology — extraction proven before anything is designed — and the range is very wide.

How often the clock restarted

We do not recommend retiring a source system until a shadow ledger has tied to its trial balance across three consecutive closed months. A material difference restarts the count.

Across migrations we have run: the clock restarted once in roughly half of them and twice in about one in six. Two restarts pushes a cutover by a quarter, and it is an uncomfortable conversation every time.

What caused the restarts is the interesting part. Roughly a third were our error — a mapping problem, a mishandled transaction type. The remainder were the customer’s existing books being wrong: an unbalanced period, a duplicate posting, a journal to a suspense account nobody had decomposed.

More restarts were caused by errors in the source system than by errors in ours. That is uncomfortable to report and it is why the rule exists.

The migrations that never happened

This is the largest category and the one most worth knowing about. A substantial share of customers who engaged us intending to migrate never did.

They connected their existing ledger read-only, got dimensional reporting and consolidation in two to three weeks, and found that the problem which triggered the search was solved. The ledger was never the constraint.

We count those as successful engagements. They are worth a fraction of what a migration would have earned us, and recommending one first remains the right answer for most companies arriving with a reporting complaint.

What made the difficult ones difficult

  • Data condition, every time. The migrations that ran long were the ones where the diagnostic was skipped or shortened. This is the single strongest predictor.
  • Report parity. Consistently underestimated. Customers count the reports they use and find twice as many once they start looking.
  • Customisation in the source system. SuiteScript, AL extensions, Acumatica framework work. None of it transfers, and where it is substantial we have told customers to stay.
  • Decision latency. Where a chart of accounts decision sat with a committee, everything downstream waited. The projects that landed fastest had one named person who could decide within a day.

What we would do differently

Insist on the paid diagnostic before quoting a fixed price, in every case. We have occasionally quoted without one to accommodate a customer’s timeline, and those are disproportionately represented among the engagements that ran long.

And inventory reports earlier. It is a two-hour exercise that consistently changes the timeline estimate, and we now do it during scoping rather than during build.

Ask us for one that went badly

We will connect you with a customer whose migration ran long, including one where the reconciliation clock restarted twice. Our own guidance tells buyers to demand difficult references from every vendor, and it would be incoherent to publish that and then decline the same request.

Questions

Common follow-ups.

How often does the clock restart?
Once in roughly half of migrations, twice in about one in six. Two restarts pushes a cutover by a quarter.
What causes restarts?
About a third are our error. The remainder are the customer’s existing books being wrong — an unbalanced period, a duplicate posting, a suspense journal nobody had decomposed.
Do most customers actually migrate?
No. A substantial share connect read-only, get the reporting they were missing in two to three weeks, and find the ledger was never the constraint.
What makes a migration run long?
Data condition, every time, and specifically where the diagnostic was skipped or shortened to accommodate a timeline.
Can we speak to a customer whose migration was difficult?
Yes. Ask, and we will connect you to one where the clock restarted twice.

Most of them were never migrations.

Connect read-only first. If the reporting problem was the actual problem, you will know in three weeks.