In this article
The internet disappears. A customer is holding a purchase. Your cashier is holding their breath. A business continuity plan should explain what happens next before this becomes a live demonstration.
On-premise ERP runs on infrastructure controlled at a business location. With a properly designed local network, selected workflows can remain available when the outside internet connection fails. That is different from a browser application having an offline mode, and different again from a payment terminal being able to accept a particular transaction offline.
Can ERP work without the internet?
It can, for the functions deliberately designed and deployed to work locally. A workstation may still reach a local server over the office network even when the ISP is unavailable. Remote staff, cloud-only integrations and services that need external verification may remain unavailable. “Offline support” needs a written list of supported actions, not a hopeful tick on a proposal.
Offline invoices are not offline card authorisations
A local POS may record a sale, print a receipt and update its local stock without the internet. Whether it can accept a card or wallet payment depends on the payment provider, terminal, configuration and risk rules. Do not treat a queued sale as a bank-approved payment. Staff need a clear pending-payment status and a reconciliation procedure.
- Confirm which billing, stock and customer actions remain available locally.
- Define how transactions are identified and how duplicate submissions are prevented.
- Separate completed payments from payments awaiting provider confirmation.
- Plan what users see when prices, stock or customer records are stale.
- Document who resolves conflicts when branches reconnect.
The local server needs power, backups and an owner
A functioning local network does not help when the server has no power. Discuss the UPS, graceful shutdown, hardware maintenance, network security, update responsibility and off-site backup arrangements. Keeping everything in the office is not automatically safer; one damaged machine should not be the only copy of the business.
Agree a recovery point objective—the amount of data loss the business can tolerate—and a recovery time objective—the acceptable restoration time. Then test restoring a backup. “We have backups” and “we can restore operations” are related statements, but they are not the same statement.
How we scope an on-site ERP Enigma implementation
We assess the operating flow, locations, users, hardware and integration requirements before deciding which ERP Enigma functions belong locally, in the cloud or in a hybrid design. Offline operation, synchronisation and payment integration must be included in the agreed scope and tested against the actual deployment. This is implementation work, not a claim that every module works offline by default.
A Pakistani retail counter may prioritise billing during an ISP outage. A US warehouse may prioritise picking and dispatch on its internal network. An EU business may need additional access, retention and transfer controls. GCC hospitality teams may need branch-level continuity, while Australian and New Zealand operators should consider distance, connectivity and recovery support. The design starts with the interruption you need to survive.
A rollout checklist that beats surprises
- Disconnect the WAN deliberately and test the agreed local workflows.
- Test a power failure and the planned recovery sequence.
- Create two conflicting updates and confirm the reconciliation rule.
- Restore an agreed backup into a test environment.
- Train the team on pending payments, manual fallbacks and escalation.
Use the test results to choose your deployment model. Cloud, on-premise and hybrid each have sensible uses. The best option is the one your business can operate and recover—not the one with the most dramatic server photo.
Discuss on-site and hybrid ERP Enigma scope ↗
Build a practical POS and inventory workflow ↗