The honest triggers
QuickBooks handles more than its reputation suggests. Plenty of companies past $20M run on it comfortably. The decision should turn on specific constraints rather than on revenue.
- Multi-entity consolidation you are currently doing in a spreadsheet every month
- Multi-currency where the manual revaluation has become a monthly risk
- Revenue recognition complexity that your team is handling with journal entries and a side schedule
- Inventory or manufacturing costing beyond what the platform supports
- Approval workflows and audit trails a lender, auditor or acquirer has asked for and you cannot produce
- User count and permission granularity, where too many people have too much access because the tool cannot express the restriction
Reasons that are not sufficient on their own
Wanting better reports, feeling that you have outgrown the brand, or an investor mentioning it once. Better reporting is usually a chart of accounts problem, and migrating a bad chart of accounts to a more expensive platform gives you the same reports at four times the cost.
Fix the chart of accounts first
This is the single highest-leverage thing you can do, and it is the step most often skipped in the rush to implement.
A migration is the one moment when restructuring the chart of accounts is cheap, because you are remapping everything anyway. Carry your existing structure across unchanged and you have paid for a new system to reproduce the reports you were already unhappy with.
- Separate the dimensions: accounts describe the nature of a cost, while department, class, location and project are separate fields
- Cut accounts that exist because somebody once wanted a report, which is how charts of accounts reach 400 lines
- Agree the reporting you want out first, then design the structure that produces it
- Map old to new explicitly and keep the map, because you will need it for comparatives
What a migration actually involves
Typical mid-market timeline is three to six months from kickoff to first clean close on the new system.
- Design: chart of accounts, dimensions, approval workflows, and who has which permissions
- Data migration: open balances, open AR and AP, and a decision about how much history to bring
- Integration: bank feeds, payroll, billing, CRM, expense and any industry system
- Parallel run: at least one full month closed in both systems and reconciled to each other
- Cutover and stabilisation: expect the first two closes on the new system to take longer, not less
The history question
Migrating years of transactional history is expensive, slow, and usually unnecessary. The common answer is open balances plus two years of summarised history in the new system, with the old system kept read-only for detail.
Decide this deliberately, because it drives a large share of the cost. Auditors are generally comfortable with a read-only archive of the prior system as long as access is retained and documented.
What it costs, roughly
- Software: NetSuite is priced per user with module add-ons, and it is a step change from QuickBooks rather than an increment
- Implementation: typically a multiple of first-year software cost when done by a partner
- Internal time: the cost nobody budgets, and it lands on your controller during a period when the close still has to happen
- Post-go-live support: budget for it, because the first two months always surface something
How these go wrong
- No parallel run, so the first discrepancy is found in month three with no baseline to compare against
- The chart of accounts carried over unchanged
- Integrations left until the end, when they turn out to drive the design
- Nobody internally owns it, so the implementation partner makes your policy decisions for you
- Go-live scheduled at quarter or year end, which stacks the hardest close on top of the newest system