Replacing barcodes in a warehouse without stopping the warehouse

01 / FIELD NOTE

Keep the decision tied to the operating context.

A warehouse moving from barcodes to tags is not replacing a device. It is changing the point at which the record is written, and that touches every process that used to write it. The work is therefore a migration rather than an installation, and the constraint that shapes it is that the building has to keep operating throughout.

The first decision is what the tag will identify, because it determines everything downstream. Tagging at pallet level makes inbound and outbound cheap and can only ever answer questions about pallets. Tagging at carton level adds resolution at the cost of more labels. Tagging each unit is the only level at which the record can speak about individual items, and it costs the most per unit. The right choice is the coarsest level that still answers the questions the business actually asks — and the questions should be written down, because "we might want unit-level later" is not one of them.

The second is which process moves first. Receiving is the usual recommendation and it is usually right: it is a bounded operation at a fixed location, the goods arrive with known expectations to compare against, and a failure there is contained to the dock rather than propagating into every downstream record. Starting with dispatch is more tempting commercially, because the visible benefit is buyer-facing, and it is harder to get right because a dispatch error has already left the building.

The third is what happens to the barcode. Retiring it on day one is a common and avoidable mistake, because a tag that fails to read at a portal has no fallback and the operation has no rehearsed response. Keeping the barcode as a defined fallback for a stated period — with a record of when it was used — gives the operation a way to continue and gives the project the data it needs about where reads are unreliable.

The parallel period is where the risk concentrates, and it deserves to be planned rather than endured. While both methods are in use, two records exist, and reconciling them by hand is worse than either alone. The practical approach is to make one authoritative and treat the other as evidence: the tag record is the record, the barcode is what someone reaches for when the tag record has nothing. That keeps a single source of truth while the fallback is still available.

The physical work is larger than it appears from a project plan. Labels have to be applied to stock that is already in the building, not just to what arrives after go-live, and someone has to decide what to do about goods that are in transit, in a returns queue, or on a site the business does not control. Each of those populations needs a stated treatment, and the ones that are omitted are the ones that produce an unexplained gap in the first count.

Tag placement is a quality decision that is easy to delegate and should not be. A tag that is applied in the wrong place — against metal, under a liquid, on a curved surface, facing the wrong way in storage — will read poorly for its whole life, and the failure will be attributed to the technology rather than to the application. A placement standard, verified on a sample before rollout, is what stops a wave of tags being applied in a way that has to be redone.

Encoding is the parallel risk and it hides better. A tag written with the wrong identifier, or associated with the wrong item in the system, produces a record that is internally consistent and externally wrong. It will survive every reconciliation until someone tries to use that specific item, which may be months later. Verifying that a sample of encoded tags resolves to the right items is a small step that prevents a large and slow-to-detect class of error.

The workflow has to change at the same time as the hardware, and this is the step most often left out. If capture becomes automatic at a portal but the process still requires an operator to stop and confirm each item, the benefit is not realised and the manual work remains. The process design question is what the person no longer has to do — and if the answer is nothing, the installation is a cost with a demonstration attached.

The material constraints decide where the method will not work, and it is better to know that before go-live. Metal racking, liquid contents, densely stacked pallets, freezer environments and read zones that overlap with a neighbouring dock all change what the radio can do. A site survey that measures the intended read points against the actual goods is what turns those from surprises in production into documented limitations with a defined alternative.

What the operation needs after go-live is an exception routine rather than a support number. Tags will not always read, documents will not always match, and goods will occasionally be in the wrong place. A defined path for each of those, with someone responsible for the queue, is what keeps the record trustworthy after the project team has moved on — and it is the part that determines whether the change held.

The measure of a successful migration is not the read rate at a portal. It is whether a count can be taken on a normal working day without stopping the operation, whether an exception can be traced to a cause, and whether anyone still keeps a private spreadsheet because the official figure cannot be trusted. The first is a commissioning reading; the others are what the migration was for.