Give your legacy business system a mobile interface
Adding mobile support to a business system is usually done through an app on top of it that talks to it via an API. If the system lacks an API, an integration layer gets built first. The key is prioritizing a few mobile workflows staff use often, instead of mirroring the whole system, and supporting offline use.
Many businesses have an ERP system that works fine in the office but forces field staff back to a desk to log what they’ve done. The fix is rarely replacing the system. More often, it means building an app that sits on top of what you already have and gives a mobile interface to just the parts needed in the field.
The API layer is the prerequisite
A mobile app that’s meant to work against an existing system needs a way to talk to it. That way is an API, a defined path in and out of the system for pulling and pushing data.
If the system already has an API, a lot is already won. Then the app can read orders, submit registrations, and update status without anyone touching the system itself. If there’s no API, an integration layer needs to be built first: a component that makes the system’s data available in a secure, controlled way.
That groundwork varies a lot depending on how the system is built. A modern system often has ready-made interfaces, while an older one can require more work. That’s why this kind of project always starts with a technical review of which ways into the system exist. The outcome of that review shapes both timeline and cost more than anything else.
Prioritize a few workflows, don’t mirror the whole system
The most common and most expensive mistake is wanting everything the business system can do inside the mobile app. A business system has been built up over many years and contains a huge number of features. Recreating all of it in an app is expensive, takes a long time, and ends up with a mobile interface just as cluttered as the system it was meant to simplify.
Do the opposite. Ask: what are the four or five things staff do most often out in the field? It could be:
- Reading today’s orders or work tasks.
- Registering completed work with time and materials.
- Taking a photo and attaching it to a case.
- Updating status so the office sees the situation in real time.
Build the app around these few workflows and make them really good. A focused app is cheaper to build, simpler to use, and considerably more likely to actually get used. Staff can keep doing the rest in the system when they’re at a computer.
A concrete scenario
Picture a service company with technicians out on assignments. Today they write up jobs on paper and enter them into the business system in the evening. An app on top of the system could instead let the technician see today’s jobs, register time and materials spent right on site, and mark the job as done.
The app doesn’t mirror the entire business system, it does those three things. The system is unchanged, but the fieldwork moves from paper and double entry to mobile. The win isn’t technical elegance but hours getting registered correctly and on time. A setup this contained is also easier to take on as a first step before expanding further.
Offline and syncing for fieldwork
A field app has to work where coverage doesn’t. Basements, warehouses, industrial sites, and rural areas are exactly where staff often are, and exactly where the mobile network fails.
That’s why this kind of app is built with offline support. That means what a technician registers gets saved locally on the phone even without a connection, and syncs with the business system automatically once the network is back. For the user it should feel seamless, you register your job and don’t have to think about whether there’s coverage or not.
Syncing needs careful handling so nothing gets lost and data doesn’t collide when several people work at once. That’s one of the areas where experience shows, and a question worth raising early with whoever’s building the app.
Want to know if your system can get a mobile interface and what it would take? Get in touch with a short description of the system and we’ll do an initial assessment.
Frequently asked questions
Do we have to replace our business system to get an app?
No, that's the whole point. A mobile app can be built on top of the system you already have and pull and push data through an API. The system stays as is, while the app gives staff a mobile way to work. Replacing the entire business system is a completely different and much bigger investment.
What's needed if our system lacks an API?
Then an integration layer needs to be built that makes the system's data available securely. That's groundwork that takes time and costs money, but it's often achievable even for older systems. A technical review shows which ways into the system exist and what they require.
Should the app do everything the business system does?
Almost never. Mirroring an entire business system in an app becomes expensive and hard to use. Better to pick out the few workflows field staff use most often, like registering a job or looking up an order. A focused app ends up both cheaper and more actually used.
Why is offline support important for a field app?
Field staff often work where coverage is poor or absent, like basements, warehouses, or rural areas. If the app only works online, it becomes useless exactly when it's needed. With offline support, what's registered is saved locally and synced with the system once a connection is back.
How long does a project like this take?
It depends entirely on whether the system has an API and how many workflows the app needs to support. An app against a system with a good API and a few workflows can move relatively fast, while an older system without an API requires more groundwork. A review of the starting point gives a realistic timeline.