Here's my verdict up front: for a new warehouse launch, integration testing time is never enough. The only question is whether you burn those hours before go-live, or after — while the customer service phones ring off the hook. I've watched too many projects spend 80 percent of their runway on slotting layouts and equipment commissioning, leaving a single week for integrations. Then on launch day, the WMS vendor, the carriers, and the marketplaces all point fingers at each other while a few hundred parcels sit at the pack stations with no shipping labels.
The sandbox is not a prop: align the environments before you test a thing
In 2024, I walked into a 120,000-square-foot greenfield site in Ontario, California, a week before go-live to review integration testing. The sandbox looked great: order in, label out, ship confirmed — a flawless demo for the executives. Launch day told a different story. The label template in the sandbox wasn't the same one configured in production. The production template carried an extra check-digit rule on the tracking-number field. Labels printed, scanners rejected them, and parcels piled up at the sorter's induction for half an hour while the whole line stood still.
The lesson is boring and specific: sandbox and production configurations must match item by item — label templates, printer models and drivers, carrier accounts, server time zones. Note the carrier accounts especially: test credentials and production credentials frequently carry different permissions. I've seen a test account that could rate-shop and print labels but couldn't pull tracking events, which meant the tracking webhook path went completely untested until launch day. Every mismatch is a launch-day incident waiting to happen. Before testing begins, build a two-column checklist — sandbox versus production — and don't start until every row is checked off.
One more thing about the sandbox: seed it with production-shaped data, not toy data. Five SKUs with one unit each won't surface anything. Load a few thousand SKUs, real dimensional weights, the actual carrier service codes you'll use, and addresses with apartments, PO boxes, and the occasional typo. Most integration bugs I've seen weren't logic errors — they were data-shape errors, and toy data hides all of them.
And on day one of testing, get all three parties to write down the API version they're running. Carrier API docs get revised three or four times a year, fields change without notice, and the version you tested in the sandbox may not be the version running in production. I make everyone confirm the production version number, in writing, at the kickoff — it saves a week of finger-pointing later.
Test the ugly cases, not the happy path
Everybody tests the normal order. The orders that kill you are the exceptions, so build the test plan around them: missing or malformed addresses, overweight and oversize parcels, SKUs that don't exist, negative inventory, cancellations after the pick has started, one order split across multiple cartons, multiple orders merged into one. Run at least three of each, and verify the order status agrees across all three systems — WMS, marketplace, carrier. The classic failure is a three-way disagreement: the marketplace shows "shipped," the WMS still says "awaiting pick," and your customer service team finds out from the angry emails.
Don't forget the ERP either. The purchase-order receiving flow — ASN in, goods receipt posted, inventory snapshot synced back — deserves its own test pass. The perennial classic is the opening-versus-closing inventory mismatch: the ERP thinks you received 500 units, the WMS counted 480, and nobody reconciles until month-end close turns into a forensic exercise. Run a full receive-to-count cycle in the sandbox and reconcile the numbers before launch, not after.
Two categories get skipped almost every time. First, the peak-volume order: a week before Black Friday, script twenty thousand orders a day into the sandbox and watch whether rate limits and message queues hold. Ten orders a second looks fine in testing; two hundred a second during peak will flatten an unprepared API. I've seen it more than once. Second, the return. Nine out of ten greenfield sites never run a complete return through the sandbox before launch, and the return path is an entirely separate chain — marketplace return authorization, WMS receiving, inspection, putaway, inventory write-back to the marketplace. If any link breaks, returns stall in limbo. The first week of returns after launch will expose every gap you didn't test.
End every testing day with reconciliation: export order statuses from all three systems — marketplace, WMS, carrier — and confirm the same batch of order numbers shows consistent states everywhere. Write the reconciliation script on day one and run it automatically; don't eyeball it. Every mismatch is tomorrow's priority bug.
Cutover day: plan the way back before you plan the way forward
Before launch, define the rollback line — in writing. If outbound accuracy drops below a set floor within two hours of cutover, or the API error rate crosses a threshold, you revert to the legacy system or manual orders immediately. Post it on the war-room wall. Don't leave it as "we'll see how it goes." In the moment, nobody has the headspace to make that call; you can only execute a rule you wrote beforehand.
Keep the old system warm on cutover day. Run old and new in parallel for half a day to a full day: orders flow into both, outbound ships from the old system, the new one runs shadow validation. Concretely, that means comparing the first fifty labels the new system prints against the old system's output, line by line — addresses, service levels, tracking numbers — before you trust it with real volume. Parallel operation costs double the labor for a day. Skipping it means betting launch day's few thousand orders on hope. Bad trade.
And staff the night shift: integration failures cluster in the first overnight hours after cutover. Development, the warehouse supervisor, and customer service each need someone on site or on call, in one group chat, with contact details pinned. Don't start dialing around looking for people after things break.
When was the last time your sandbox ran a complete return — marketplace return initiated, WMS receiving, inspection, putaway, inventory written back — end to end? If you can't name the date, push cutover back a week. Integration testing has no "close enough." Production will find every corner you cut, one by one, on launch day.
