Last updated: August 14, 2026
Move from QuickBooks to NetSuite once entity count, inventory, or consolidation has outgrown a single ledger, and run it as a governed project with named decision gates, not a data transfer with a due date. The software takes six to twelve weeks to configure. The other four to seven months is people agreeing on things.
Week ten of a migration I watched from the sidelines, somebody in sales asked for “one more report.”
Customer-level margin, broken out by the three legacy price books nobody had gotten around to retiring. Reasonable ask. The developer building the order-to-cash flow said sure, quietly, because it looked like forty minutes of work stapled onto a Tuesday.
It was forty-three hours. Spread across three weeks, because the report needed a customer segment dimension that hadn’t been mapped anywhere in the design, and mapping it after the fact touched six saved searches that had already been tested and signed off.
Nobody logged it as a change. There was nothing to log it against, because nobody had ever written down what a change was.
Two disclosures before I get into it, because you should weigh the rest against them. I run an ERP consulting shop, so a company deciding it needs migration help is a company that might eventually call me. And you’re reading this on a staffing firm’s blog. Both of those color what follows. I’ll come back to the second one.
If you’re still deciding whether the move is warranted at all, that’s a different article, and I already wrote the honest version of it in the signs you’ve outgrown QuickBooks. Short version: entity count, inventory you can’t trust, and a close that has become a named project are the real triggers. Revenue isn’t. This piece assumes you’ve already answered that question, or you’re close enough that the answer doesn’t matter yet, and you want to know what actually happens between saying yes and your first NetSuite close.
KORE1 has staffed ERP consultant staffing since 2005, and most of what follows comes from watching who gets hired onto these projects and what breaks when the wrong seat is empty. The staffing model, the bench, and what the roles cost live on QuickBooks to NetSuite migration staffing. This one is about how the project itself should run once you’ve decided to make the move.
When, in One Paragraph
Three things push a company off QuickBooks. Multiple legal entities consolidated by hand. Inventory numbers that get corrected after the fact more than they get trusted the first time. A margin question that takes days instead of an hour to answer with a number anyone would repeat to a lender. One of those is a process fix. Two or three together is a platform decision.
That’s the whole test. Nothing longer coming. Everything past this point is about the part almost nobody writes about honestly, which is what happens after you’ve decided and before you’re live.
Nobody Fails at the Software. They Fail at the Governance
I said this about implementation mistakes in a different post and I’ll say a version of it again here because it’s the whole thesis. NetSuite configuration is not the hard part of this project. It never has been.
Panorama Consulting’s most recent ERP implementation research finds 55% of ERP projects run over budget and 68% run behind schedule. That’s across every platform, every vertical, every project size. Nothing on that list is unique to migrating off QuickBooks. What’s on that list is nobody deciding, in advance, what a change is and what happens when one shows up mid-build.
PMI’s research on this is blunter. Scope creep touches roughly half of all projects, and the ones that avoid it aren’t the ones with better software. They’re the ones with somebody whose job is to say “that’s a change, here’s what it costs, here’s who has to approve it” before the work starts, not after somebody notices the timeline slipped.
Borrow the Discipline Regulated Companies Are Forced to Use
On the regulated side of my business, we run formal change classification because the FDA makes us. Every modification to a validated system gets sorted into one of three buckets before anyone touches it. I’ve started recommending a lightweight version to companies migrating off QuickBooks who have never once thought about change control. It’s cheap. Costs about a week of somebody’s time to stand up. And in my experience it’s the single highest-impact thing separating the projects that land on budget from the ones that don’t.
Here’s the adapted version. Nobody needs an FDA-grade version of this for a mid-market accounting migration. You need the shape of it.
| Class | What triggers it | What happens |
|---|---|---|
| A | Doesn’t touch scope, cost, schedule, or anything already tested. A field label, a saved search tweak, a typo in a workflow name. | Project manager approves it inline. Recorded, not escalated. |
| B | Adds hours, moves a date, or touches something outside the original design document. The margin report above. | Written change order. Cost, schedule impact, and who requested it, before anyone builds it. |
| C | Touches something already reconciled or already signed off, like the opening balance or a tested integration. | Change order plus a re-test of whatever it disturbed. Nobody re-signs a reconciliation from memory. |
Class A is most of what comes up. Class B is where projects quietly bleed, because a hundred small B’s dressed as A’s is how you get to go-live forty hours over with nobody able to point to the hour they went over.
One more piece worth stealing, and it’s the part that actually protects you financially. Split waiting from rework. If a delay is your vendor’s fault, or the bank feed export took longer than promised, or finance hasn’t approved the chart of accounts yet, that buys schedule relief and nothing else. Nobody owes anybody money for a Tuesday spent waiting. If the delay is rework, meaning somebody built the wrong thing or a requirement changed after build started, that’s billable. Label it that way in the change order. Not folded into “additional configuration hours” on an invoice three weeks later. Ask any partner scoping your project whether they separate the two. Most don’t, because blending them hides which one is actually driving your budget.
The Report Nobody Classified
Back to week ten.
By the time anyone noticed the margin report had eaten forty-three hours, the project was already two weeks from parallel testing. There was no budget line for it because there was no change order, and there was no change order because nobody had ever agreed on what would trigger one. The project manager found out from a timesheet, not a request.
Here’s the part that actually hurt. Badly. Testing got compressed by four days to absorb the overrun, because the go-live date was fixed to a board meeting and nobody wanted to be the one who moved it. The compressed testing window is exactly where the customer segment dimension conflict surfaced, in the first parallel-run close, when two of the legacy price books produced margin numbers that didn’t tie to the general ledger by about six thousand dollars. Somebody had to chase that down during what was supposed to be a quiet reconciliation week.
Nothing about that story required a bigger team or a smarter developer. It required one sentence, agreed in week one: anything over eight hours or touching a tested integration goes through a change order before it gets built. That sentence costs nothing. Skipping it cost three weeks of testing time and a reconciliation nobody wanted to run twice.
The Five Decisions That Actually Move the Needle
Not the six-stage project plan your implementation partner will hand you. Those are mostly the same everywhere. These are the five decisions that determine whether that plan survives contact with your actual company.
- Who has stop authority. One name, not a committee, who can say “we’re not going live Friday” and have it stick without a re-vote. If that person doesn’t exist, the go/no-go call defaults to whoever is loudest in the room the week of cutover, which is a genuinely bad way to make that decision.
- Where the change-order line sits. Pick a number. Eight hours. Sixteen. Whatever fits your project size. Below it, the PM approves inline. Above it, it’s written down with cost and schedule attached before anyone builds it. Most companies never pick a number, which means the default number is infinity and every change slides through as “well, we’re already in there.”
- Hard cutover or a parallel run. A hard freeze is cleaner and riskier. A parallel month running both systems catches reconciliation problems before they’re load-bearing, and costs you a slower close for one cycle. Multi-entity and inventory-heavy businesses should run parallel almost every time. Single-entity, clean data, a weekend freeze is usually fine.
- What “done” actually means. Not go-live. The first month-end close that ties in NetSuite without a spreadsheet propping it up, signed off by whoever owns the financial statements. Write that definition down before the project starts, or “done” quietly becomes “the day the consultants left,” which is a different thing and a worse one.
- Whether you’re doing any of this at all. A single-entity company with clean books moving a straightforward general ledger genuinely doesn’t need a formal change classification scheme. One person can hold that in their head. The rule of thumb I use: if you can’t name every open decision in the project from memory on a Friday afternoon, you’ve crossed into needing it written down.
Who Actually Runs This Well
The projects that stay boring, in the good sense, almost always have the same shape. A finance systems analyst who understands accounting first and NetSuite second, sitting inside the project rather than bolted onto it. A project manager with actual authority to say no to a request rather than a scheduler tracking a Gantt chart nobody updates. And somebody, anybody, whose job includes classifying a change before it becomes forty-three hours nobody can account for.
KORE1’s ERP desk fills that bench in about 17 days on average, with 92% of placements still in the seat a year later. That’s not a governance stat, I know. It’s a staffing stat. But an unstaffed decision gate is the same as a decision gate that doesn’t exist, and the fastest way companies blow this up is leaving the classifying-a-change job unassigned for the first six weeks while everyone assumes finance or IT already owns it.
If you already know you need the seat and just need to fill it, that’s ERP implementation project manager staffing for the gate-keeping role, and contract staffing if you’re not sure yet whether it’s permanent. Run the free ERP readiness assessment before any of this if you’re still one step earlier than a project plan, and the NetSuite implementation cost calculator is a decent gut check against whatever number a partner just handed you. If the fork you’re actually stuck on is whether to staff this yourself or hand it to a consultant, KORE1 already ran that comparison in NetSuite consultant versus in-house team.
Questions Worth Asking Before You Sign a Statement of Work
Who should actually have stop authority on cutover night?
One named person, almost always the controller or CFO, not the implementation partner. The partner is financially motivated to hit the date on the contract. Whoever owns the financial statements is the one who has to defend the opening balance to an auditor eighteen months later, so the authority belongs with them.
Isn’t formal change control overkill for a company our size?
For a single entity with clean books, mostly yes. A one-page version is enough. Once you’re multi-entity or the project runs past twelve weeks, the informal version stops working, because nobody remembers what was agreed in week two by week nine.
What actually counts as scope creep versus a reasonable mid-project ask?
If it wasn’t in the design document your team signed off on, it’s a change, full stop, even if it takes twenty minutes. The size of the ask has nothing to do with whether it needs to be logged. Small unclassified changes are exactly how the big overruns happen, one Tuesday at a time.
Should finance and IT split the go or no-go decision?
Split authority is how cutover decisions get made by whoever argues longest at eleven at night. Pick one owner, usually finance since they own the number that has to tie, and give IT veto power only over items that would create a data integrity problem, not a preference disagreement.
Do we need a parallel run, or can we do a straight cutover?
Complexity decides this, not company size. A clean single-entity ledger with simple order-to-cash can freeze over a weekend. Multiple entities, inventory, or any consolidation logic should run a parallel month, because that’s when reconciliation problems surface while you still have the old system to check against.
What happens to a change nobody classified in time?
It becomes technical debt with a due date. Untested, unbudgeted work gets absorbed into whatever testing window is left. That’s precisely how a forty-three hour report turns into a compressed test cycle and a reconciliation gap, surfacing during the worst possible week to find one.
Count the Changes
Ask your project manager one question next week. Right now, if you’re mid-migration. How many changes have we made so far that never got written down anywhere?
If the answer is zero, either you’re running a cleaner project than almost anyone I’ve talked to, or nobody’s counting. Both are worth finding out which.
Governance sounds like the boring half of this project. It’s actually the half that decides whether your go-live date holds. The software configures itself in six to twelve weeks either way.
Run the count and hit me up on LinkedIn with what you find. If the gap is a missing seat rather than a missing process, that’s the part I’m genuinely no help with. Bring it to the KORE1 team instead.
