Selecting Warehouse Scanners to Replace StayLinked Guns

The fleet is 15-year-old handheld scan guns running StayLinked terminal emulation into Oracle. They work but are clunky, and IT is pushing back on phones and tablets because of durability and how well they scan barcodes. Run the checks below in order. Each one names the reading to take and which branch it sends you down. The last two sections cover the pilot that gates the purchase and the cutover checks for the device class you choose.

Check 1: Integration path from StayLinked into Oracle

Prerequisite: a list of every Oracle transaction the guns perform today, such as receiving, putaway, picking, cycle count and shipping, and the screens each one uses.

StayLinked is a terminal emulation layer. The session and the Oracle integration live on the server, and the handheld acts as a thin client that renders screens and sends keystrokes and scan data. This drives the whole decision. Replacing the hardware does not change the integration unless you also replace the application layer.

Reading to take: ask the operators what "clunky" means. Is it the device (slow boot, weak scanner, dim screen, worn keys) or the workflow (too many screens, keyed entry, fields that don't fit)?

Path	What changes	What stays	Who owns the work
Keep terminal emulation on new rugged hardware	Device, scan engine, battery, display	Oracle screens, transactions, server-side session	StayLinked licensing and client deployment; IT staging
Move to a WMS app that connects to the ERP	User interface, workflow, label handling	Oracle as system of record	WMS vendor plus WMS-to-Oracle integration project
In-house app with a commercial barcode-scanning SDK	Everything on the device side	Oracle back end	Your developers, including long-term maintenance

1. If the complaint is hardware, keep terminal emulation. Confirm with StayLinked that a client is supported on the candidate hardware and OS, and whether existing licenses transfer. Then go to Check 2.
2. If the complaint is the screens themselves, new hardware running the same emulated screens will still feel the same, only faster. Evaluate a WMS or native app path. One site running ShipHawk WMS connected to its ERP moved fully to tablets and phones and reports GS1 labels are fully supported. Go to Check 2 with touch-first devices in the candidate list.
3. If you choose the SDK path, budget for development and ongoing app maintenance before comparing hardware prices. The SDK makes any camera device a scanner, but the app becomes your product to support.

Check 2: Barcode read performance on your worst labels

Prerequisite: a test set of real labels. Include stretch-wrapped pallets, torn or smudged labels, labels on curved or glossy surfaces, the longest scan distance you use (racking height, forklift seat to pallet), and every symbology you print, including GS1 formats.

Phone and tablet cameras decode barcodes in software from a general-purpose image. Dedicated scan engines add purpose-built illumination, an aimer, and decode tuning for glare, low contrast and damage. The gap is small on clean labels at arm's length and wide on wrapped or damaged labels. Dedicated industrial readers widen the gap further. Keyence readers stand out at reading through pallet wrap and damaged labels, but expect to need an integrator to make them do anything beyond basic reading.

Reading to take: first-pass read rate per device across the test set, plus time to a successful read on the hardest labels.

1. If the camera-based device reads the worst labels on the first pass at a rate your operations accept, phones and tablets stay in the candidate list. Go to Check 3.
2. If camera decoding fails on wrapped or damaged labels, restrict candidates to devices with a dedicated scan engine. Go to Check 3.
3. If one fixed location (a dock door, a conveyor, a wrap station) produces most of the hard reads, evaluate a fixed industrial reader for that point instead of oversizing every handheld. Plan integrator time for it.
4. Whatever the device, confirm that the application parses GS1 application identifiers into the correct Oracle fields. A device that decodes the barcode but passes one unparsed string into a single field has not passed this check.

Check 3: Battery swap and charging discipline

Warehouse staff forget to put devices on the charger. When the battery is sealed, that device is out of service until it recharges. Swappable batteries fix this: charged spares sit in a charger, and an operator grabs one and keeps working. Consumer phones almost never offer this, which rules them out for many floors.

Reading to take: for one week on the current fleet, log how many devices die before end of shift, the shift pattern (single, double, continuous), and whether devices are shared between shifts.

1. If devices run multiple shifts, are shared, or die mid-shift at any measurable rate, make swappable batteries a hard requirement. This removes most consumer phones from the list.
2. Size the spare battery pool from measured runtime on the pilot device against your longest shift, not from a datasheet figure. Add multi-bay chargers at the point where devices are issued.
3. If all devices are single-shift, personally assigned, and reliably docked, sealed batteries remain acceptable. Carry the weaker power resilience into the pilot scoring.

Check 4: Form factor matched to each workflow

A single device model rarely fits every task. Map workflows to form factors before you standardize.

Device class	Example in service	Field notes	Fits
Android all-touch rugged computer	Zebra TC56	Functions as an Android device; built-in push-to-talk gave a large productivity gain where workers already wore headsets for voice picking	Touch-first WMS apps, mixed scan and communication
Rugged handheld with physical keyboard	Zebra MC3300x	Performs well; choose the keyboard layout carefully for your data-entry pattern	Terminal emulation screens with keyed quantities and locations
Vehicle mount	Zebra VC8300	Well liked by operators, very expensive	Forklift and reach-truck putaway and replenishment
Wearable	Zebra WS50	Expect development work to make it fit the workflow	Hands-free, high-rate picking
Consumer phone or tablet	Varies	Easiest to use with a touch WMS; weaker durability and usually no swappable battery	Low-intensity scanning, office-adjacent receiving, supervisors

1. If you are staying on terminal emulation with numeric entry on most screens, weight physical-keyboard handhelds heavily. Emulated screens on an all-touch device push keyed entry onto a soft keyboard.
2. If operators already use headsets or radios, count integrated push-to-talk as a feature that can replace a separate device.
3. If a wearable or vehicle mount is the right fit, confirm that your application runs on it unmodified before you price it. The wearable in particular should be budgeted with development time.

Check 5: Lifecycle cost per device

One field data point for a rugged Android handheld (Zebra TC56, purchased early 2018): roughly $1,200 per device including a 3-year full-coverage warranty. Renewal is about $400 every 3 years per device, and the renewal includes software updates. Those units remained in service years later with no replacement planned. Treat these as historical figures and get current quotes.

Derived cumulative cost per device, assuming the $1,200 purchase includes the first 3-year term and renewals continue at about $400:

Service life	Cumulative cost (hardware + coverage)
3 years	~$1,200
6 years	~$1,600
9 years	~$2,000

The argument that phones have a lower total cost of ownership holds only if the full cost is compared on both sides. Build the comparison from the same formula for each candidate:

TCO(N years) = hardware + protective case/holster
             + warranty or replacement budget (breakage rate x unit cost)
             + spare batteries and chargers
             + software licenses (TE client, WMS seats, or SDK)
             + device management
             + downtime cost (dead or broken devices x lost labor hours)

Take breakage rate and dead-device rate from the pilot, not from brochures. A phone that costs a fraction of a rugged device can still cost more over the service life if it breaks more often, has no swappable battery, or needs a case and an SDK license to reach parity. A 15-year-old fleet also shows the other side of lifecycle cost. Check the vendor's published OS and security-update support period for each candidate model, because the renewal cost above is what keeps software updates flowing.

Floor complaints mapped to device-class causes

Use this table to turn pilot feedback into a decision instead of a preference vote.

Symptom on the floor	Likely cause	Branch
Device dead before end of shift	Sealed battery combined with missed charging	Check 3: require swappable batteries
Repeated no-reads on wrapped pallets	Camera decoding fighting glare and film reflection	Check 2: dedicated scan engine or fixed reader
Slow entry on quantity and location screens	Emulated keyed screens on a soft keyboard	Check 4: physical keyboard, or Check 1: app path
Cracked screens and broken ports	Consumer hardware without a rugged housing	Check 5: breakage feeds the TCO; move to rugged
Still "clunky" on new rugged hardware	The emulated screen flow, not the device	Check 1: WMS or native app path
GS1 label scans but wrong data lands in Oracle	Barcode decoded but application identifiers not parsed	Check 2, step 4: fix parsing in TE or app

Floor pilot gating the purchase

Settle the IT durability objection with measurements. Run the pilot on the actual floor, not in the IT office.

1. Select candidates. Pick one device from each class that survived Checks 1-4, at minimum one rugged dedicated-engine device and one phone or tablet if phones are still in contention. Gate: every candidate completes a full Oracle transaction in a test environment before it goes to the floor.
2. Stage identically. Load the same application (TE client or WMS app), the same symbology set, and the same scan-to-field behavior on every candidate. Gate: a scan of each test label populates the correct field on every device.
3. Assign to real users on real workflows. Include your heaviest scanners and at least one forklift or picking role. Gate: each device completes full shifts, not partial demos.
4. Log per device per shift: first-pass read rate on the hard-label set, scans per hour, battery level at end of shift or swaps performed, drops and damage, and transaction errors in Oracle. Gate: at least a week of data per candidate before scoring.
5. Collect structured operator feedback on grip, trigger or scan-button placement, screen readability, and keyboard use. Gate: feedback is tied back to the symptom table above, not recorded as a general preference.
6. Score against the TCO formula using the measured breakage and dead-device rates. Gate: IT and operations sign off on the same numbers.

Cutover to the selected device class

Prerequisite: pilot sign-off, license counts confirmed with StayLinked or the WMS vendor, and a spare battery and charger plan sized from pilot runtime.

1. Build one golden device configuration covering the application, scan engine symbologies, GS1 parsing, Wi-Fi profile and keyboard layout. Confirm that it completes every transaction on the Check 1 list against the Oracle test instance.
2. Clone the configuration to the fleet through the device management tool. Confirm by spot-checking the settings on several randomly chosen units.
3. Deploy charged spare batteries and chargers at each device issue point before handing out devices. Confirm that every issue point has spares on charge at the start of shift.
4. Cut over one area or one shift at a time, keeping the old guns available as fallback. Confirm with zero unresolved Oracle transaction errors from that area before moving to the next.
5. Retire the old guns only after the full fleet has run a complete week of all shifts.
6. Final verification: rescan the Check 2 hard-label set on production devices in each area. Compare the first-pass read rate and end-of-shift battery results against the pilot figures, and confirm that the Oracle records created by those scans carry the correct GS1-parsed values in every field.

FAQ