Move a Batch of Orders to a Different Warehouse

1. Purpose

To move a group of orders to a different ship from warehouse in one action, and to have that decision survive every later refresh. Editing the warehouse on each order looks like it works and does not last, which is the reason this document exists.

2. Scope

Covers re-routing orders that already exist in Ship Side Kick, for organizations that have a warehouse routing automation. Does not cover creating the routing rule itself, moving physical stock between buildings, or splitting a single order across two warehouses.

3. Roles & Responsibilities

4. When you need this

Use it when a stock outage at one site means today's orders have to ship from another, when a brand is being migrated between buildings and its open orders need to follow, or when weather, a closure or a missed carrier pickup takes a site out for the day. Also use it whenever you find yourself about to edit the warehouse on more than two or three orders by hand.

5. Key concept: the warehouse on an order is an output, not a decision

This is the single thing that makes people think the feature is broken, and it accounts for nearly every ticket on warehouse routing.

So the rule is: do not edit the field, tag the order. The tag is durable and the field is not.

6. Procedure

1. Confirm the destination warehouse can actually cover the orders. Tagging moves the order, not the stock, so an order sent to a site without inventory will sit unallocated there instead of where it started.

2. Go to Orders and filter to the orders you want to move. Filtering first matters, because the tag applies to the current selection and it is easy to catch more than you meant.

3. Select the orders with the checkboxes. The selected count appears alongside the bulk actions, so check it against what you expected before going further.

4. Open the bulk actions and choose Add Tag to Orders.

5. Enter the warehouse tag for the destination site, in the form warehouse: followed by the site name, for example warehouse:tops. Confirm the exact values with support the first time. A tag the rule does not recognise is accepted without complaint and simply does nothing.

6. Apply the tag.

7. With the same orders still selected, choose Refresh Orders. This is the step that rebuilds the tasks so the rule re-runs and reads the new tag. Without it, nothing changes and the tag looks like it failed.

7. Verification

Do not trust the tag appearing as proof the move worked. The tag is only an instruction, and the rule has to run before anything changes.

Open one of the orders and confirm it shows the destination warehouse. Then refresh that same order a second time. If the warehouse holds, the tag matches what the rule expects. If it reverts, the tag value is wrong and every order in the batch needs the corrected tag.

Finally, check that allocation reflects stock at the new site rather than the old one.

8. Constraints and caveats

The tag sticks until it is removed. An order tagged during an outage keeps going to that site long after the outage ends, so clearing the tags is part of the job rather than an afterthought.

Orders that have already been picked will not simply re-route. Unpick them first or leave them where they are.

Removing a tag hands the decision straight back to the rule, which may immediately route the order somewhere you did not intend. Remove tags deliberately, not in bulk at the end of a week.

Tagging does not reserve stock at the destination. If two people tag overlapping batches to the same site, the second batch can find the inventory already spoken for.

9. Worked example

A 3PL runs warehouse routing for two brands, with a rule that tags each order with its intended ship from site. They asked how to move a batch when a stock outage forced a change, having already found that editing orders one at a time did not hold.