Northwest Auto's ERP migration, from the warehouse sideNorthwestAuto'sERPmigration,fromthewarehouseside

Northwest Auto Distribution moves automotive parts out of four warehouses in Idaho, Washington, and Montana. About 38,000 SKUs, 90% of which are slow-moving and 10% of which turn weekly. They had been on QuickBooks Enterprise for seven years and Nautilus for two. In February, they made the decision to migrate from QuickBooks to NetSuite.

Doug Vargas, their VP of Operations, called us the week before they signed the NetSuite contract. He had one question: was there any reason this would break Nautilus?

The honest answer was that we had never done an ERP swap underneath a live customer before. We had migrated customers onto Nautilus from various ERPs, but we had never had a Nautilus customer change which ERP we connected to. So we said: probably not, but let's walk through it.

What they were actually changing

The change at Northwest Auto was about accounting and finance, not warehouse operations. QuickBooks Enterprise was straining at their scale, especially around consolidated reporting across the four facilities. NetSuite gave them better reporting, better multi-entity handling, and a runway for their planned expansion to two more locations next year.

From the warehouse floor, the change should be invisible. Operators don't see the ERP. They see Nautilus on their phones. The ERP is the thing on the back end where receipts post against purchase orders and cycle count variances close out to journal entries.

But the integration is real. A receipt in Nautilus updates the QuickBooks inventory ledger in real time. A cycle count variance closes against a QuickBooks adjustment account. The connection runs both ways, and there was no version where we could just unplug QuickBooks one Friday and plug NetSuite in on Monday without something going wrong.

The plan

We landed on a four-phase plan, which took about three months to execute.

Phase one (two weeks): mirror the chart of accounts. NetSuite's account structure was different from QuickBooks's. Their finance team built the mapping table. We pulled it into Nautilus's integration config in dry-run mode, where the system would compute what it would have posted to NetSuite for every actual operation without actually posting anything. We compared dry-run outputs to live QuickBooks postings for two weeks. About 4% of operations produced different journal entries, all of which traced to expected mapping decisions (asset category renames, location code differences).

Phase two (three weeks): dual-write. Nautilus posted to both QuickBooks and NetSuite simultaneously. NetSuite was the test target; QuickBooks remained the source of truth. The accounting team reconciled NetSuite's books against QuickBooks's books weekly. Any drift was investigated and resolved. By the end of phase two, NetSuite and QuickBooks were producing identical balances within a small rounding tolerance.

Phase three (one week): cutover. NetSuite became the source of truth. QuickBooks went into read-only mode. Nautilus posted only to NetSuite. The accounting team continued reconciliation against the QuickBooks shadow for the first week as a check.

Phase four (ongoing): retirement. QuickBooks data was archived, the QuickBooks integration was disabled, and Northwest Auto's finance team transitioned to NetSuite-only workflows.

What broke

We hit three meaningful issues during the migration, all in phase two.

The first was negative-quantity handling. QuickBooks and NetSuite have different conventions for posting a negative inventory adjustment. We had to add a small abstraction layer in the integration that normalized the convention at our end, so the same logical operation produced sensible journal entries on either platform.

The second was multi-location consolidation. QuickBooks had treated Northwest Auto's four warehouses as four separate inventory locations with manual consolidation in reports. NetSuite has a more flexible multi-subsidiary model. We had to map each Nautilus warehouse to a NetSuite location and a NetSuite subsidiary, which required a Northwest Auto operational decision: do the warehouses count as separate subsidiaries for tax purposes, or one. They chose the latter, which simplified things.

The third was timing. NetSuite's API rate limits are tighter than QuickBooks's. During high-volume periods (Monday morning receiving, end-of-month cycle count) Nautilus had to back off and batch. We adjusted the integration's batching strategy and the issue went away.

What didn't break

Receiving, picking, putaway, counting, shipping, and reporting on the warehouse floor were unaffected. The operators saw the same Nautilus app on Monday morning that they had seen on Friday. No retraining was needed.

We asked Doug to ask his floor managers, two weeks after cutover, if they had noticed anything different. The first answer was "different about what?" The second was "you mean the new accounting system? When did that happen?"

That's the answer we wanted. The integration layer absorbed the migration so operations didn't have to.

What we kept from this

Two things.

First, the dual-write pattern is now the default for any customer doing an ERP migration with us in the loop. We had considered it overkill before this; it isn't. The two-week reconciliation period catches mapping errors before they become real accounting errors, and it's much cheaper than retroactively unwinding three weeks of incorrect journal entries.

Second, we wrote a runbook for ERP migrations and have used it twice more since Northwest Auto. The runbook is internal but the headline is: plan for ten weeks, schedule the cutover for a Tuesday (not a weekend, because you want your engineers and theirs available), and rehearse the rollback.

Northwest Auto's NetSuite go-live was March 17. As of this writing they have been on NetSuite for two months. Inventory accuracy is unchanged. Operator satisfaction (we ask quarterly) is unchanged. Doug's last note to us said the finance team is happier than they have been in years. That was the goal.