Insights9 February 2025Updated 25 October 20264 min read

Legacy System Modernisation: When Mobile Wrappers Leave Field Teams Stranded

Legacy system modernisation infographic showing mobile wrappers failing field teams and promoting offline first apps for enterprise efficiency.

A mobile container and an offline workflow are different engineering decisions. Ionic describes Capacitor as a container for a web application with access to native APIs. For legacy system modernisation, we recommend judging the proposed application by the work a field team can complete without a connection, rather than by whether it installs on a phone.

That means replacing the blanket question, “Do we need a native app?” with a specific one: “Can a technician open an assigned job, record an inspection and keep the result when the network is unavailable?” Use that workflow as the first acceptance test. Treat the example as a test to design, not a claim about a particular organisation's results.

Separate the container from the workflow

Calling an application a wrapper says little about its design. Capacitor places web code in a managed native Web View and exposes native functionality through plugins. A team should therefore inspect what the application actually does before accepting or rejecting that approach.

Ask the supplier to demonstrate the same job on the intended device with networking disabled. Include opening the application again after closing it. Require the demonstration to cover the screens, reference data and attachments that the person needs, rather than a cached landing page.

Do the same for hardware access. The Capacitor announcement describes camera access and native plugins. That is a reason to assess a web-based container on its implementation, not to assume that web code rules out device features. It is not evidence that a particular camera workflow is fast enough or usable with gloves. Test those requirements separately.

Keep web applications in the shortlist

The opposite shortcut is to assume that a browser application cannot support disconnected work. The W3C's Service Workers specification describes hooks for starting web applications while offline. That establishes an architectural option, not a promise that an existing website already uses it.

For structured records, the Indexed Database API defines records with keys and values, with indexes for locating them. Treat storage and application start-up as separate items in the design review. Ask which records will be available locally and which operations still need the server.

Our recommendation is to compare implementations against the same acceptance tests. Include a browser application where it meets the requirements, a container where device integration warrants it, and native development where the proposed workflow calls for it. Do not award an option a pass solely because of its framework name.

Modernise one business operation at a time

A replacement mobile screen does not settle how the legacy system will receive its data. Review that boundary before building the interface. Choose one business operation, such as submitting an inspection, and write down its inputs, validation rules and accepted result.

AWS describes incremental replacement behind an API facade: the existing system and new services remain accessible through a common interface while functions move. This gives a concrete alternative to replacing the entire application at once. It does not require us to recommend the particular AWS deployment for every project.

For a field application, use that pattern as a design prompt. Specify which system owns each record and which service accepts a change. Require the mobile team and the legacy team to agree how a rejected submission will appear to the user. Keep the scope small enough to demonstrate the whole operation, including the return path, before extending the migration.

Define what saved means

Write separate acceptance criteria for a local save and a server-accepted submission. For the proposed inspection workflow, require a visible pending state after a disconnected save. Require a different state after the server has accepted the result. Avoid a single “success” message that leaves the reviewer guessing which event happened.

Then test interruption at the boundary. Disconnect after sending a submission but before displaying the response. Repeat the submission. Close and reopen the application. Edit the same test record from another device. For each case, specify the expected result before asking a builder to implement it.

These are recommended tests, not a guarantee that a particular storage API or framework resolves conflicting edits. Ask the team to show its chosen conflict rule and the evidence that the implementation follows it. Where a human must decide, include the review screen in the demonstration.

Make guided decisions explicit

The same approach applies to a diagnostic questionnaire or an inspection checklist. Start with the questions, permitted answers and next actions. Label which decisions the application may make locally and which need a current server response or a person's approval.

Use named examples to review those rules with the people responsible for the work. Include missing information and an answer that changes an earlier decision. Where the rules are versioned, require the test record to identify the version used. Do not promise fewer errors simply because the process has become a decision tree. Make any outcome claim depend on measured results from the actual workflow.

For Dendro Logic, the first useful deliverable is that agreed operation and its tests. Ask for one end-to-end demonstration on the intended device, with a deliberate connection failure and a checked server result afterwards. Use the result to decide what to modernise next.

Update, October 2026

For teams using agents to implement these changes, our engineering article on gated build loops and independent review describes a delivery approach. Keep the field-work acceptance tests explicit when delegating the implementation.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →