Cloud vs on-premise ERP: choose an operating model

Define the deployment terms

SaaS, hosted and on-premise describe different operating arrangements, and vendors use these labels differently. Ask who owns the application, infrastructure, database and upgrade schedule. Confirm whether environments are shared or dedicated and which controls the customer can configure.

Map the operational responsibility

Assign ownership for backups, restoration, access reviews, monitoring and incident response. Review service commitments and the practical escalation path. Test how users continue critical tasks during an outage. Availability claims should be interpreted alongside the contract and your own continuity requirements.

Price the full operating model

Include internal administration, patch testing, hardware or hosting, integrations and upgrade projects. Check whether a customization restricts future upgrades. Compare equivalent test and production environments. The lowest initial cost can hide ongoing work that sits with your team.

Select against your constraints

Document connectivity, plant devices, data-processing requirements and integration needs. Run a recovery exercise and a representative upgrade test if these are critical. Neither model is universally better. Make the decision on the responsibilities and constraints your organization can sustain over the life of the system.

Write the responsibility matrix in verbs

For each layer, state who configures, monitors, patches, restores and approves change. Cover identity, application, database, infrastructure, interfaces and plant devices. In SaaS, the provider may operate the platform while the customer still owns access design and integration recovery. With an on-premise application, an external partner may perform much of the administration. Hosted software can fall between these arrangements. Ask who has privileged access and how that access is reviewed. The useful distinction is the set of responsibilities your organization retains, not the physical location implied by a label. Have each supplier confirm its row in writing and reconcile it with the proposed service terms.

Design continuity around the next operational deadline

List the tasks that cannot wait: receiving a hazardous or perishable load, releasing a carrier shipment, recording a tracked material issue or making a payroll handoff. Assign an acceptable interruption based on the real consequence and available manual process. Distinguish recovery time from the amount of recent data that could be lost. Do not set targets merely because they appear in a brochure. Ask the provider what is contractually committed and what must be designed by the customer. Include local internet, identity service and label-printing failures. A functioning remote application is little comfort when a plant cannot authenticate or print the document needed to move goods.

Reconcile after recovery

Illustrative example: a plant writes down 30 receipts during an interruption, while the warehouse integration already queued 12 of those events. On restoration, entering all 30 manually and replaying all queued messages can duplicate stock. These are fictional quantities used to expose a recovery question. Specify how events receive identities, how pending work is located and who authorizes replay. Reconcile physical movement, application transactions and external acknowledgments before resuming normal processing. Business Central's restore documentation describes product-specific considerations and limitations. It does not mean every surrounding service is restored automatically. For any deployment, test credentials, connectors, scheduled jobs and outbound communications as part of the recovery exercise.

Assess customization against change frequency

List every proposed extension and whether it changes core behavior, adds a separate component or uses supported interfaces. Ask how it is tested against the vendor's update schedule. A tightly controlled SaaS release can reduce platform administration while requiring regular customer testing. An on-premise deployment can offer more scheduling discretion while leaving patching and eventual upgrade work with the operator. Neither removes the need for a maintained test pack. Prioritize workflows where a change could affect stock, financial postings or external commitments. Require an environment plan covering realistic test data, access and isolation of outbound messages. A copied database that emails real suppliers is not a safe rehearsal environment.

Test the plant edge

Inventory the scales, scanners, printers, machine gateways and shared workstations that connect to the application. Identify driver, browser, network and identity requirements. Run a realistic shift path with the actual device class and label format. Test a dropped connection midway through a scan and a session timeout with a partially entered receipt. Decide what can be queued locally and what requires an online transaction. Offline operation is a specific capability to demonstrate; do not infer it from either cloud or on-premise deployment. Also examine remote administration of devices across sites. The support burden can sit in these local dependencies even when the central application is fully managed.

Make exit a practical portability test

Choose a sample entity and request export of masters, transactions, tracking relationships, audit records and attachments within the proposed access rights. Inspect whether identifiers remain usable outside the application and whether lookup codes are explained. Clarify timing, extraction charges, assistance and post-termination access in the commercial discussion. For on-premise software, possession of a database does not automatically make its contents intelligible or licensed for future use. For SaaS, a spreadsheet export may omit important relationships. Keep the responsibility matrix, continuity runbook, device inventory and export test with the decision record. These artifacts explain why the selected operating model can be sustained after the implementation team leaves.

Common questions

Continue your research

The following profiles provide a starting point for checking vendor-described scope. Inclusion is not a ranking or a statement that every requirement is supported.