Windows CE to Android PDA migration: what actually breaks, and how to plan it

The device on the forklift is still running Windows CE because nothing about the workflow forced a change. The application was written by an integrator who used the vendor's Compact Framework toolchain and has since retired; the scanner feeds characters into whichever field has focus; the scan trigger is a mapped hardware key; the configuration lives in the registry; and the deployment ran over an ActiveSync partnership from a machine that has itself been replaced twice. Microsoft's support obligations for those handheld platforms ended years ago, and the development tools that build for them sit on obsolete host operating systems. The estate keeps working anyway — which is exactly why the migration, when it finally comes, arrives as an emergency rather than a programme.

This is the migration itself: the software-portability question, the four other things that break between the two input models, a decision tree, and a pilot with exit criteria you can defend. Choosing and managing Android handhelds once they exist is covered elsewhere — see the rugged Android PDA selection and fleet-management material, and the FAQ answers on GMS and non-GMS devices — and none of that helps before there is an application to run.

Why the estate survived this long

Four reasons, and each predicts a specific migration obstacle. The application is locked to a toolchain nobody in the building still owns. The scanner is wired in through a driver-level trick — serial or keyboard emulation — that no application team thinks of as "the integration". The workflow was designed around a keypad and a trigger, so nobody asked whether a touchscreen could carry it. And the estate is held up by spare units bought on the secondary market, whose lithium cells are now its real end-of-life clock. These four items are the scope.

The five things that break

1. The application itself

Code written for the .NET Compact Framework does not run on Android, in any mode. There is no CF runtime, and the WinForms-style controls, the CE windowing assumptions and the platform invokes — calls into coredll.dll, the registry API, the CE power and messaging interfaces — have no counterparts. If you own the source, some of it survives as logic: business rules and parsing written in C# can be re-targeted, and a modern .NET-for-Android toolchain takes much of it at source level. What never survives without a rewrite is the user interface, and anything that touched the OS. If you do not own the source, the application is a black box with an expired build chain, and the honest options are reimplementation from observed behaviour or living with the old platform.

2. How scan data reaches the field

On CE, the reader delivered bytes one of two ways: a virtual serial port the application opened, or a keyboard wedge that synthesised keystrokes into the focused control. The wedge is the one that will surprise you. Android has no equivalent of injecting keystrokes into whatever window happens to be active: input goes through an input method, or through the device vendor's SDK, which typically returns decoded data through a service callback or a broadcast intent that the application must explicitly subscribe to. So the integration moves from "the operating system does it" to "our application calls a vendor library", and every code path that assumed free-form character input has to be revisited — including focus handling, including the fact that password and secure fields refuse synthetic input, and including what happens when a scan arrives while the app is backgrounded. Ask for the payload contract in writing: which application identifiers are parsed, which prefixes and terminators are attached, and whether separator characters survive.

3. Hardware keys and the scan trigger

CE exposed physical keys as scan codes that a registry remap table could route to application-defined virtual keys, and vendor applications were built assuming that function row. Android delivers key events, but an ordinary application cannot remap system keys, and a factory can legitimately ship a device whose trigger reports through the SDK rather than as a keycode at all. Two practical consequences: an app that read keys directly needs rework even where its logic survived the port, and a workflow built on twelve buttons plus a trigger may not have a keyboardless equivalent. This is why keypad-bearing rugged Android terminals exist at all — EDOO lists M71 as a rugged 4G Android PDA with a physical keypad, which is the shape to look for when gloves, cold and muscle memory make a soft keyboard the wrong answer, and M91 as an Android 12 rugged 4G PDA for the workflows that do migrate.

4. Storage, paths and the file-based integration

CE used a rooted file system with no drive letters — \Windows, \Program Files, \Storage Card — where applications wrote freely beside their own executable, kept settings in the registry, and exchanged data with the desktop through a partnership folder. Android gives each application a private directory, forbids casual writes outside it, and tightens shared external storage with every release for scoped-storage reasons. So a migration that "only" changes the operating system still has to relocate: local databases, the offline transaction queue, licence files keyed to a path, log output, and any integration that worked by dropping a file into a folder something else polled. Registry keys become application configuration, a path becomes an app-private location, and a desktop partnership becomes a server endpoint.

5. Deployment and enterprise management

CE deployment was a sync partnership or a CAB pushed from a desktop tool, with the same console serving device identity, application install and reset. Android's equivalent is Android Enterprise delivered through an EMM/MDM: zero-touch or QR enrolment, managed configurations, device-owner lockdown and a policy channel. Two traps sit on that boundary. First, GMS-certified and non-GMS devices are different procurement classes: a non-GMS build can be locked down harder and cheaper, but it cannot use the Play-managed channels your new MDM may depend on, and an application expecting Play services fails quietly. Second, certification is a per-model question you must ask in writing — EDOO's rugged range spans Android 12, 13 and 14 by model, so the OS floor and the Google-services status vary across otherwise similar-looking terminals. Check both against the certificates listed under technical recognition.

Migration decision tree

There are four destinations, and the choice is driven by one question: do you own the application's source and its future?

standard and the old app only did what any COTS product does; cost moves from porting to configuration and integration, and the WMS interface becomes the project.

when the application encodes genuinely differentiated process knowledge and you can fund a real development cycle.

client is acceptable — but it converts an offline-capable device into a network-dependent one, which in a cold-store aisle or a basement plant room changes the workflow, not just the technology.

Cheapest for twelve months, most expensive for sixty, because spares get scarcer each quarter and no support escalation sits behind them.

• Retire and buy software. Replace the CE client with a maintained warehouse or field app and specify Android hardware to run it. Correct when the workflow is
• Rewrite on the vendor SDK. Keep the workflow, rebuild the client natively, and take ownership of the scanner service, key handling and offline queue. Correct
• Wrap the app in a remote session. Re-host the business logic server-side and have the handheld run only a display client. Correct where a browser or remote
• Keep CE as bridge hardware. Buy a bounded stock of surviving units and drivers, freeze the workflow, and schedule the software decision instead of triaging it.

If the application is a 2007-era data-entry client with no maintained source and the requirement is "the same screens on a device we can still buy", the cheapest honest path is a lift-and-shift terminal-emulator or browser client on Android hardware, accepting the network dependency. Some of those applications will never be portable, and a plan pretending otherwise wastes a pilot.

A phased pilot with exit criteria that survive contact

Phase 0 is the step everybody skips, and it is why migrations get approved on the wrong evidence. If you never measured the old fleet you cannot prove the new one is better, and you will lose every argument with the operators who tell you the CE units were fine. Fix the thresholds before phase 1 starts, keep the old units running beside the pilot as a control group, and name the abort criterion in advance — a data-integrity defect in phase 2 should stop the programme, not generate a ticket.

Driver and SDK compatibility, tested rather than assumed

Treat the scanner service as a dependency with its own version, because it is one. Verify that the SDK builds against your current target API and is still maintained; that the callback or broadcast payload matches your expected output for every symbology, including GS1 separators and symbology identifiers; that the SDK version and the firmware of the scan engine are a supported pair, since an update can reset symbology enables and terminators; that scans arrive while the app is backgrounded or the screen is off; which channel the trigger and keys report through, and that it matches what the application reads; and that lockdown does not let power management kill the scanning service. Run all of it against the label deck you already own — the same physical artefacts your old devices read — so the comparison is a measurement rather than a mood.

CE-era assumption → Android reality → verify before the pilot

What the vendor needs from you, and what you need from them

An ODM will happily ship hardware; the migration artefacts are a separate purchase. Ask for the scanner SDK with documentation and a maintenance commitment, the configuration command set and flashing route for the fleet, the keymap for your build, the shipped OS version with its end-of-support date, and a serial manifest per shipment — EDOO publishes OEM quantities from 100 units with 15-day samples and 30-day production, which is a workable window for one round of the pilot above. Put those clauses in the same agreement as the hardware, and confirm pilot-unit terms with the contact team; the artefacts themselves are listed on the ODM/OEM and product documentation pages.

FAQ

Can a Windows CE application be converted to run on an Android PDA? No — .NET Compact Framework binaries have no runtime on Android, and the WinForms controls and CE platform calls they rely on have no equivalents, so a migration is either a source-level reimplementation of the business logic against an Android UI and vendor scanner SDK, or a decision to stop running that application at all.

What replaces keyboard-wedge scanner input on Android? The device vendor's SDK, service callback or broadcast intent that the application subscribes to explicitly, or an input-method and HID-keyboard route where the host application accepts synthetic key events; unlike CE there is no system layer that types into whichever control has focus, so every field that relied on it has to be reviewed.

How long does a Windows CE to Android PDA migration take? Plan roughly three to four months for the pilot stages of a single-application estate — a baseline measurement on the existing units, a bench test of the input pipeline, and a shadow deployment of eight to fifteen devices in one zone — with the software rewrite, if there is one, running in parallel and usually dominating the schedule.

What is the cheapest path when the old application cannot be ported? Re-host the functionality rather than the code: move the business logic server-side and run a terminal-emulator or browser client on Android hardware, or replace the application with a maintained package and spend the budget on integration — and if neither is fundable this year, buy a bounded bridge stock of CE units with a written date by which the software decision gets made.

Related EDOO resources

Android PDA and POS terminals · technical-recognition · Barcode scan engines · ODM / OEM services · Product documentation and SDKs · Contact EDOO · FAQ · M71 product page · EDOO product datasheet