Switching NetSuite marketplace connectors: a channel-by-channel cutover that never creates a duplicate sales order

The risk

Where a NetSuite connector switch actually goes wrong

Two things break during a connector migration, and both come from having two systems touch the same marketplace at the same time. The first is duplicate sales orders: the old connector and the new one both see an Amazon or Walmart order and both create it in NetSuite, and finance spends the next week finding the pairs. The second is inventory: the new connector starts pushing quantities to a channel before it has a complete, current picture of what NetSuite holds, and listings show numbers that are stale on day one. A cutover plan that avoids both does not need a hard switch date. It needs an order check before every push and an inventory pull that has already been running before any channel starts receiving quantities.

Cutover sequence

One sales channel at a time, with the old connector still running

InfiPlex runs in parallel with the connector you are leaving. Most clients pick a single channel to start: that channel is turned off in the old connector and turned on in InfiPlex, its orders begin landing in NetSuite as sales orders under the InfiPlex connection's rules, and once the team is comfortable the next channel follows. Amazon can move this week, Walmart next week, the Shopify store after that, in whatever order matches your volume and your comfort level. Every channel lands in the same InfiPlex order queue alongside the channels still on their way over, and each one pushes to NetSuite with the same NetSuite integration configuration, so the last channel to move behaves exactly like the first.

Duplicate prevention

Every order is checked in NetSuite before it is pushed, then checked again

Before InfiPlex pushes any order to NetSuite, it checks NetSuite for that specific order. That check happens no matter what, on every order, and it is double-checked before the push goes through. An order the old connector already created is found and left alone; an order nothing has created yet is pushed once. This is what makes the overlap window between two connectors safe rather than something to schedule around: if a channel is briefly live in both systems, NetSuite still ends up with one sales order per marketplace order. The same check protects you after the migration is over, when a retry, a manual re-import, or a replayed pull might otherwise produce a second copy.

Inventory during the switch

Quantities are current before any channel starts receiving them

InfiPlex pulls inventory from NetSuite regularly by modified date, across every NetSuite location you map to an InfiPlex warehouse, and that pull runs from the moment the connection is live, independent of whether any channel is receiving quantities yet. Sending inventory to a sales channel is a separate switch, enabled or disabled channel by channel. That separation is what lets a channel move its orders first: you confirm sales orders are landing in NetSuite the way you expect, then enable inventory sends for that channel and the number it receives is already current, because the pull has been keeping it current the whole time. The per-channel controls covered in the multichannel inventory sync guide, including which warehouses each channel sees, set-to-zero thresholds, and per-SKU buffers, apply from the first send. If your NetSuite account has Advanced Item Location Configuration enabled, the connection reads location-level inventory through SuiteQL, the one path that still returns it; the failure and recovery guide covers why.

Configuration

What gets set up on the InfiPlex side, and how channel SKUs reach NetSuite item IDs

Filters, mappings, and rules are configured on the InfiPlex NetSuite connection rather than exported from the old connector, which is usually the point of the switch. Order pull rules run as filter-and-action pairs on standard or custom NetSuite fields, post-pull actions can write a value back to NetSuite or map any NetSuite field into InfiPlex, and specific SKUs such as a freight surcharge line can be excluded from ever becoming a product line on the order. Channel SKUs reach NetSuite through SKU maps associated to the connection: each row carries a source SKU, a destination SKU, and a destination quantity, so a marketplace SKU pushes under the item ID NetSuite knows, and tracking and inventory pulled back are reverse-mapped to the channel SKU without a second configuration. The item does need to exist in NetSuite in some form, since the push requires a NetSuite item ID. Tracking pushes to NetSuite when an order is marked fully shipped, with multiple packages combinable into one on the NetSuite side and specific order sources excluded from that consolidation when they need to stay itemized. Connection-level choices, SOAP or REST with machine-to-machine authentication, are made per Site Area.

On-demand

Backfilling orders that landed during the switch

Orders normally pull on a schedule, but a specific list of NetSuite order IDs can be imported into InfiPlex immediately, on demand, without waiting for the next cycle. During a migration that is the clean answer to the handful of orders that arrived in the gap between turning a channel off in one system and on in the other: give InfiPlex the IDs and they come in now, under the same pull rules that apply on schedule, so nothing skips your filters because it was requested manually. The NetSuite integration FAQs cover the day-to-day questions once the switch is behind you.

Frequently asked

Questions, answered

Resources

Related pages

Planning to leave your current NetSuite connector?

We move marketplace channels onto InfiPlex from other connectors regularly. Tell us which channels you run, which NetSuite locations feed them, and what your current connector is getting wrong, and we will map out the channel order with you. Contact us, email info@infiplex.com, or call 888‑770‑0857.