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.
Customers
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.
Tell us your source system and entity count. We will give a realistic timeline, not a planned one.
Customers
Time to cutover, then the parallel period after it. Both measured as actually elapsed rather than as originally planned.
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.
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.
Median 3 weeks to cutover, 8 weeks parallel. Extraction is easy; remapping two tracking categories into real dimensions across history is the work.
Median 5 weeks to cutover, 9 weeks parallel. Dimensions transfer cleanly, which is unusual. Report parity is the part customers underestimate.
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.
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.
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.
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.
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.
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
Connect read-only first. If the reporting problem was the actual problem, you will know in three weeks.