Switching Fulfilment Partners Without Breaking the Delivery Promise: A Migration Runbook for D2C Brands

Most fulfilment migrations do not break on the day the stock moves. They break in the hours around it, when a product page is still promising two-hour delivery to a pincode whose inventory is sitting in a truck on the highway. Your customer never sees the migration plan. They see a promise you made and did not keep.

Most guides on switching 3PL providers assume one warehouse emptying into another. A quick commerce network is different: inventory sits across many small nodes, each promise is backed by a specific node, and customers experience the switch one pincode at a time. That changes what you protect, and in what order.

This runbook is for founders and operations leads who have already decided to move. If you are still evaluating partners, start with how to tell whether a fulfilment partner's SLA is actually good. Everything below assumes the contract is signed and the clock is running.

In short: to switch fulfilment partners without breaking your delivery promise, migrate the promise before the stock. Map every place you tell customers when an order will arrive, step those promises down on the pincodes you are about to move, seed inventory node by node, cut over one city at a time behind written go/no-go gates, and keep the outgoing partner live until its tail of COD remittances, returns and RTOs is closed.

Why is switching fulfilment partners harder in quick commerce than a warehouse move?

Because in quick commerce the unit of risk is the pincode, not the warehouse. In a conventional 3PL migration, the worst case is a few days of slower dispatch while stock is in transit, and customers on a three-to-five-day promise barely notice. In a dark store network, each node backs a promise to a small catchment. If that node is empty while the promise is still live, the failure is immediate, visible and measured in hours.

The implication is that the standard sequence, move the stock and then switch routing, is backwards for quick commerce fulfilment. You fix the promise first, then move the stock, then switch routing, one catchment at a time.

What should you lock down before you give notice?

Three things: a node-level performance baseline, the exit terms that govern how fast you can leave, and a reconciled inventory position. Each becomes harder to secure once the outgoing partner knows you are leaving.

A baseline you can hold the new partner to

Record, for each city and node, the numbers you will later use as go/no-go gates: on-time delivery against the promise actually shown to the customer, first-attempt delivery rate, order-to-dispatch time, stockout rate and RTO rate. The quick commerce fulfilment KPIs every D2C ops lead should track are a sensible starting set. Without a baseline, every post-migration dip becomes an argument between two partners instead of a decision you can make.

Exit terms that set the real timeline

In practice, the notice period in your current contract often sets the migration timeline more than the operational work does. Before serving notice, confirm how and when stock will be released, what outbound handling will cost, who bears shortages or damage found at release, when the security deposit is refunded, and in what format order and tracking data will be handed over. Above all, check whether the contract allows a staggered, city-by-city exit. A pincode-level cutover depends on it.

An inventory position both sides have signed

Ask the outgoing partner for a stock report by node, SKU and batch, and reconcile it against your own records before anything moves. Shortages are far easier to settle while stock is still in their custody. For shelf-life categories such as nutraceuticals, food and beauty, check expiry by node as well. Paying freight to move stock you will write off at the new node is an avoidable loss.

How do you protect the delivery promise during the switch?

Build a Promise Ledger before you move a single unit. It is one register of every place your brand tells a customer when an order will arrive, mapped to the node and partner that backs that promise, with a named owner for turning each promise down and back up.

Most brands have more promise surfaces than they realise, and different teams own them:

1. Product page delivery badges, dates and pincode checkers (ecommerce team).
2. Checkout ETAs and shipping method names (storefront or platform team).
3. Order confirmation, WhatsApp and SMS templates and the tracking page (CX or retention).
4. Ad creatives and landing pages that sell on speed (performance marketing).
5. Support macros that quote delivery windows (support team).

The core rule is to step promises down, not switch them off. Moving affected pincodes from a two-hour promise to same-day keeps a speed promise on the page while buying the slack a move needs. Removing it gives that advantage away. Leaving it live while stock is in transit is the most expensive option, because a promise that slips quietly costs more trust than one adjusted openly. Customers tend to judge you on whether you keep the promise rather than how fast it is, so a slightly slower promise that holds is the better trade.

The ledger also makes restoration deliberate. Promises go back up only when the restore condition is met, which stops a team from restoring the delivery date on the product page simply because the new partner's first day looked fine.

How should you move inventory between fulfilment partners?

Seed the new network in the order demand requires, document every movement correctly for GST, and reconcile at receipt rather than at month-end.

Transfer, sell through, or both

There are three ways to get stock into the new network. You can transfer existing stock, sell through what the old nodes hold while routing new purchase orders to the new partner, or combine the two. The hybrid is often the most practical in quick commerce: transfer fast movers so new nodes open with depth where it matters, and let the long tail sell down where it already sits. The right mix depends on stock turns, shelf life and how much runway your notice period gives you.

Seed by demand, not by catalogue

A new node stocked with the full catalogue but thin on top sellers will post a worse stockout rate on day one than the node it replaced. Seed using node-level demand, the problem covered in demand forecasting for quick commerce dark stores, and count at receipt, node by node, with any discrepancy raised inside an agreed window.

The GST paperwork for moving stock

Moving stock between partners is usually not a sale, but it is still a movement of goods, and the documents depend on your GST registrations rather than on who owns the stock.

1. Same GSTIN, same state: moving goods between places of business under one registration is not a supply. The goods travel on a delivery challan, which is also the basis for the e-way bill when one is needed.
2. Different GSTINs: stock moving between your separate registrations, for example from one state to another, is a supply between distinct persons even without consideration, and inter-state stock transfers attract IGST. That needs a tax invoice, not a challan.
3. E-way bill: Rule 138 of the CGST Rules requires one when a registered person moves a consignment worth more than ₹50,000, and state tax departments confirm this applies to movements for reasons other than supply as well.

That ₹50,000 figure is not universal. Rule 138(14) exempts specified goods and situations, and each state notifies its own intra-state threshold and exemptions, so a transfer within one state can follow different rules from one between states. The procedure has also shifted this year: GSTN proposed new e-way bill requirements in 2026 and later withdrew them, leaving the existing rules in place. Before stock moves, confirm with your tax adviser that each new partner facility is registered as a place of business on the right GSTIN, and check the current rules for your specific route. Our guide to GST e-invoicing and e-way bill rules for quick commerce dispatch covers the outbound side. This section is operational guidance, not tax advice.

What does a pincode-level canary cutover look like?

Pick one city, then one pincode cluster within it. Route that cluster's orders to the new partner under a stepped-down promise, and expand only when it clears gates you wrote down before the move started.

The idea comes from software releases: expose a small slice first, then widen or roll back based on what it shows. In fulfilment, the slice is a catchment. Choose a cluster with enough daily orders to be meaningful but not your highest-revenue catchment, with a representative SKU mix and no campaign running.

Two conditions make this work. First, the outgoing partner stays live in each city until that city clears its gate, because a rollback needs somewhere to roll back to. Running two partners in parallel costs money in split inventory and double storage; treat it as the price of a reversible migration. Second, routing must be controllable at pincode level in your storefront or order management system, with order status, tracking links and NDR events flowing back from whichever partner holds the order.

One more thing moves with the orders: your standards. Packaging specifications, inserts, quality checks, COD handling and doorstep conduct need to transfer as written SOPs, not as habits the old partner's team carried in their heads. They are easier to enforce where riders are full-time employees rather than gig workers rotating across platforms, because training reaches a stable team rather than a rotating pool.

What does the old partner still owe you after go-live?

More than most teams plan for. The outgoing partner's tail runs on after the last forward order: cash, returns, failed deliveries, disputes, stock and data. A tail-closure checklist gives each item an owner and a closing date, so nothing stays open by default.

The data line deserves particular care. A fulfilment partner holding your customers' names, addresses and phone numbers is processing personal data on your behalf. Under the Digital Personal Data Protection Act, a business may engage a data processor only under a valid contract, and the Act's substantive obligations come into force on 13 May 2027. Put data return and deletion terms into the exit plan now, with legal counsel confirming the specifics. Returns need the same deliberateness: deciding early who owns reverse pickups is part of building a returns process that protects margin.

Where Zippee fits

Zippee is quick commerce fulfilment infrastructure for a brand's own channel: dark stores that pick and pack to the brand's SLAs and SOPs, with delivery by full-time employed riders rather than gig workers, and integrations with platforms brands already run, including Shopify, WooCommerce, Unicommerce and EasyEcom. Because orders are placed on the brand's own website, changing fulfilment partner moves the fulfilment, not the customer relationship.

For a migration, that model matters in the places this runbook stresses most: SOPs that become written standards for a trained team, and one operator accountable when a promise slips. Our view of Quick Commerce-as-a-Service for Indian D2C brands explains the model in more depth.

The migration your customers never notice

A well-run migration is invisible to the customer. That happens only when the promise moves first, each city earns its cutover against its own baseline, and the old partner's tail is closed rather than abandoned. Treat the switch as a sequence of decisions with owners and gates, not a moving date.

If you're ready to turn your fulfilment into a competitive advantage, join our waitlist.