Free tool

Realistic weeks to cutover

Migration estimates go wrong in a predictable direction, and the cause is almost always the same: the plan was built before anyone looked at the data. This estimator makes data condition an explicit input rather than an assumption.

Get a real estimate

A one-week diagnostic replaces every slider here with a measurement. Findings are yours regardless.

1 / 3
Data condition is an inputParallel run counted separatelySource system multipliers published
3
3
Messy
Extraction & mapping3w
Entity structure2w
Data remediation2w
REST API, clean extraction8 weeks to cutover · 6 weeks parallel after

Weeks to cutover, plus the parallel-run period after it. The parallel period is not optional in our methodology and it is not padding.

How to read it

Three things this is telling you.

The headline number matters less than which of the three bars is longest, because each one has a different remedy.

The source system sets a multiplier

QuickBooks Online is the baseline. QuickBooks Desktop is roughly three times the work, legacy on-premise more. That multiplier applies to everything else, so it compounds.

Entity count is superlinear

Entities do not add fixed work. Each adds intercompany relationships with every other one, which is why nine entities costs far more than three times what three does.

Data condition is the variable that moves most

Between clean and unknown, the remediation bar goes from nothing to the largest component. It is also the input people are least able to answer honestly before a diagnostic.

Why parallel running is counted separately

Cutover is when the new system starts producing the numbers. Parallel is the period when both systems run and are compared, and the old one is retired only when the new one has agreed for two full cycles.

Most estimates omit it, which is why so many migrations feel like they went live and then continued for another quarter. It is not padding — it is the control that converts a high-risk cutover event into an evidence-based decision, and we have extended it on several engagements rather than cutting it short.

Cutover is a date. Retiring the old system is a decision, and it should follow the evidence rather than the plan.

The estimate that is always wrong

In our sample of stalled implementations, 24% failed primarily because the data was worse than anyone knew — and in almost all of those it was discovered during load rather than during a diagnostic phase that had nominally happened.

The reason is that data assessment is frequently a questionnaire rather than an examination. Looking properly requires read access, a week, and somebody willing to report bad news before a contract is signed, and the incentives run against all three.

Answering the data-condition slider honestly

Clean means you have measured your duplicate rate, every balance sheet account has been reconciled within the last quarter, and dimension data is populated on historical transactions. Almost nobody is here.

Typical means a duplicate rate around eight percent, one or two untied accounts, and dimensions introduced part-way through history. This is where most companies actually are.

Messy means known problems — an unbalanced period, a chart of accounts nobody has pruned, master data that has never been deduplicated. Unknownmeans you have not looked, and honesty about that is worth more here than optimism.

What shortens a migration

Fixing the data before rather than during. Loading three years of history rather than seven, when the older periods are unlikely to be queried. Deferring anything not needed in the first six months. And starting with integration rather than migration, so the shadow ledger proves the dataset ties before any cutover is contemplated.

What is behind the numbers

Source multipliers are derived from our own engagement history: QuickBooks Online at 1.0 as the baseline, QuickBooks Desktop at 3.0, legacy on-premise at 3.4, spreadsheets at 2.4. These reflect elapsed effort rather than calendar time.

Entity scaling uses an exponent of 0.72 applied to entity count, which fits our observed data better than linear scaling. It reflects that intercompany relationships grow faster than entity count does.

The parallel period is 55% of the cutover estimate with a floor of six weeks. In practice the criterion is two full cycles of agreement rather than a duration, so a fast-closing group exits parallel sooner than a slow one.

This is an estimator, not a quote. Every real engagement is scoped after a diagnostic, and the fixed price comes from that rather than from this page.

Questions

Common follow-ups.

Why is QuickBooks Desktop three times the work?
No cloud API. Extraction runs through the SDK against a company file on a machine somebody maintains, and list cleanup is most of the engagement.
Is the parallel period optional?
Not in our methodology. It converts a high-risk cutover into an evidence-based decision, and we have extended it rather than cut it short on several engagements.
How do I answer the data-condition slider?
If you have not measured your duplicate rate and reconciled every balance sheet account this quarter, you are not "clean". "Unknown" is an honest answer and a common one.
Can we load less history?
Yes, and it is one of the few reliable ways to shorten a migration. Three years rather than seven, when older periods are unlikely to be queried.
Is this a quote?
No. Every engagement is scoped after a diagnostic and the fixed price comes from that, not from this page.

The data is worse than you think.

It is the single most common cause of overrun and the cheapest thing to establish in advance.