Ask any Acumatica VAR where margin goes on a project and the answer is always the same. Data migration. Unexpected integrations. A custom workflow from the old system nobody mentioned until week six. A customer who said their data was clean.
It wasn't clean.
These are execution problems. But they almost never start at execution. They start in discovery — specifically, in the questions that didn't get asked before the proposal went out.
There is one question above all others. Most VARs skip it. Not because they don't know to ask it. Because the proposal timeline is short, the competition is real, and asking hard questions feels like slowing the deal down.
It isn't. Skipping it is what slows you down — six months later, on a project that's running 60 hours over and a customer who's frustrated.
The question most proposals never ask
Here it is: "What does a clean record look like in your current system — and how many of your records actually meet that definition?"
Not "how many records do you have." Not "are you planning to migrate everything." Those questions get vague answers and vague answers produce vague estimates.
This question forces specificity. It asks the prospect to define their own data quality standard — and then self-assess against it. The gap between those two answers is your migration complexity. It is also, in most cases, the gap between your estimate and what the project actually costs.
Data migration is the line item that turns a 180-hour implementation into a 260-hour one. It is almost never scoped accurately on the first proposal — because the discovery question that would surface the complexity was never asked.
Why consultants skip it
There are three reasons this question gets dropped.
First, the prospect doesn't know the answer and saying so feels uncomfortable. Consultants sense this and move past it. They make a note to revisit data migration during kickoff. They never revisit it before the contract is signed.
Second, the answer changes the estimate. A prospect with 40,000 items in a legacy system — half of which haven't been touched in three years, a third of which have duplicate entries — needs three to four times the migration hours of a clean 8,000-record environment. That's a proposal you might not win. So consultants anchor on the optimistic version and hope for the best.
Third, "data migration" looks like a single line item on the scoping template. It gets a range — 20 to 40 hours — and moves on. That range was designed for a clean, small dataset. It was never designed to hold a real answer.
What the answer actually reveals
When a prospect can answer the question precisely, you learn three things that change the estimate.
Volume alone tells you little. Structure tells you everything. A company with 5,000 customer records and no standard naming convention needs more migration work than a company with 25,000 records and a clean master data policy. Ask what the data looks like, not how much there is.
Legacy custom fields are scope multipliers. If the current system has custom fields that the business actually uses — for reporting, for workflows, for customer-facing processes — those need to map somewhere in Acumatica. Or they need to be retired, which requires a conversation that takes time. If no one asks about this in discovery, it surfaces in implementation.
Deferred cleanup becomes your problem. Most companies know their data needs work. They've been putting it off for years. When an ERP implementation appears on the horizon, the plan is often to "clean it up during migration." That cleanup doesn't happen before the migration. It happens during it. On your hours.
The question isn't whether the data has problems. It does. The question is whether the estimate accounts for what it will take to move that specific data into Acumatica in a usable state.
| Discovery Finding | Scope Impact |
|---|---|
| Legacy custom fields in active use | +15–30 hours per unmapped field cluster |
| Duplicate or inconsistent master data | +20–60 hours for deduplication and normalization |
| No documented data ownership | +10–20 hours for stakeholder alignment alone |
| Prospect expects "cleanup during migration" | Multiply migration estimate by 1.5x minimum |
| Clear data standard, documented record count | Baseline estimate holds |
How to use the answer in your estimate
Once you have a real answer, build the migration estimate around what you actually heard — not a template range.
If the prospect can't describe their data quality standard, that's an answer. It means no standard exists. Price accordingly.
If they say "most of it is fine," ask them to pull a sample. Five minutes on a screen share during discovery will tell you more than an hour of interview questions. You are looking for: duplicate entries, inconsistent formats, blank required fields, and records that haven't been updated since the previous system was implemented.
Document what you find. Put it in the SOW as a discovery assumption: "This estimate assumes customer master data is substantially clean per the client's definition provided on [date]. Migration hours will be reassessed if data quality deviates from this baseline."
That one sentence has protected more implementations than any other line in a contract.
The estimate that holds is the estimate built on real answers
Scope creep is not inevitable. It is predictable. The projects that run over are the ones where the hard questions were deferred — where the estimate was built on assumptions because the discovery call stayed comfortable.
One question, asked precisely and early, changes the entire shape of the project. It surfaces the complexity before the contract is signed. It gives you a defensible estimate. It gives the customer a realistic expectation. And it protects the margin you spent years building.
Ask the question. Document the answer. Build the estimate around what's actually there — not what the proposal timeline made it convenient to assume.
Tired of estimating in the dark?
The Clarity AI Acumatica Implementation Estimator is built for exactly this problem. Configure modules, complexity factors, and your own billing rates — then generate a SOW and project Gantt in minutes. No guesswork, no template ranges.
See the Estimator →