Cloud ERP for Manufacturing: Test Outages and Data Exit

Before buying cloud ERP for manufacturing, test three things: how the factory works when access fails, who can recover trustworthy records, and whether you can retrieve usable data when leaving. A smooth online demonstration does not answer these questions. Ask the supplier to demonstrate them with a small, agreed test job before committing to a rollout.

This guide is for owners, operations managers, and software project leads at small manufacturers, including India. It provides a continuity and exit test, not a product ranking. For the broader build-versus-buy decision, start with custom ERP versus ready-made ERP.

What does the cloud service actually include?

Cloud ERP runs enterprise resource planning functions using remotely hosted computing resources. The NIST definition of cloud computing distinguishes service and deployment models; the word cloud alone does not specify who maintains your application, integrations, devices, or operating procedures.

Ask whether the offer is a managed application subscription, a hosted installation, or a custom system on rented infrastructure. Record who owns application updates, extensions, backups, monitoring, user access, and support. Remote access and reduced local server work may be useful benefits, but compare the actual responsibilities rather than assuming they disappear.

List the tasks that must remain controlled: material issue, approved drawing access, production reporting, quality release, and dispatch. Each needs a named owner, an acceptable interruption, and a permitted fallback. A fallback should never bypass a quality hold or a safety-critical instruction.

Separate four different access failures

• One device fails: test another authorised device and user session. Do not solve it by sharing an administrator password.
• The factory internet fails: test the approved alternate connection, if available, and identify work that must pause.
• The ERP service fails: another internet connection will not repair the application. Check the supplier's incident channel and factory fallback procedure.
• Sign-in or an integration fails: the ERP may be reachable while a user cannot authenticate or one transaction flow is delayed. Make that partial failure visible.

Run controlled tests in an authorised trial environment. Do not disconnect production systems or interfere with machine controls to simulate an outage. Record the detection method, responsible contact, escalation route, and restart decision for each case. Ask how staff will access incident instructions if the usual login service is unavailable.

Decide which work can continue safely

An offline screen is not automatically an offline workflow. Ask which functions actually work without connectivity, where records are stored, how users are authenticated, and what happens when two people change the same information. Require a demonstration if offline capability is important; do not infer it from a mobile app or cached page.

Where an approved paper fallback is appropriate, give each movement a unique reference, event time, item, unit, quantity, source and destination, job reference, operator, and reviewer. Mark it as awaiting system entry. Assign one capture route so a later scanner upload does not repeat a manual entry.

For an inventory system for manufacturers, the key question is whether a delayed movement can be reconciled without hiding a shortage or releasing held stock. Agree the stock states using the main inventory management guide. Do not allocate stock from an old downloaded balance as though it were current.

Likewise, define how a supervisor confirms that an offline drawing is still approved. If that cannot be established, stop the affected job. A continuity plan preserves control; it does not authorise production to proceed on uncertain instructions.

Run a small outage-and-recovery drill

The following is a hypothetical acceptance test, not a customer result. In a sandbox, item TEST-01 starts with 100 usable pieces and no other movements. Before the connection is interrupted, a 12-piece issue is submitted, but its confirmation is lost. During the simulated interruption, a permitted 5-piece issue is recorded on fallback slip F-002.

1. Keep the first submission's reference. After access returns, check whether it was committed; do not blindly submit it again.
2. If the 12-piece issue exists, link its confirmation to the original reference. If it is proven absent, use the agreed recovery route to record it once.
3. Enter the 5-piece issue with F-002 as its source reference. Repeating the import or entry attempt must not silently create a second issue.
4. Confirm the final usable balance is 83 pieces, both issues have identifiable records, and no fallback slips remain unexplained.

Also test an unresolved case: the system cannot yet prove whether the first submission succeeded. It should remain an exception for investigation, not trigger a guessed correction. Ask the supplier to show the user-visible status and the evidence used to resolve it.

Keep this drill focused on business acceptance. The implementation may use transaction identifiers or duplicate detection, but the observed result matters: every authorised movement recorded once, with an explainable balance. For connected systems, use the related ERP integration guide to identify the responsible system at each handoff.

Distinguish reconnection from database restoration

A temporary connection failure does not by itself justify restoring yesterday's database. Restoration can move records back to an earlier point while physical work has continued. Ask who is authorised to request a restore, what recovery points are available, and how later work will be identified and reconciled.

As a product-specific example, Microsoft's Business Central restore documentation describes restoring into a new environment, restricted administrator permissions, and checks around integrations before normal use resumes. This is not a promise that every cloud ERP has the same controls.

Request a witnessed sandbox restore and a written responsibility list. Who verifies stock, unfinished jobs, attachments, permissions, and connected systems? Who prevents two environments from sending transactions at the same time? Record the observed recovery time and any missing records for your test; do not treat it as a guaranteed recovery commitment.

Prove the data exit before you need it

Ask for an export of one complete test job: item identity, applicable BOM revision, material movements, operation records, quality decisions, attachments, and change history. Open it outside the normal application and follow the relationships. A readable stock total alone cannot reconstruct why a particular job used a particular material lot.

Separate a report download, a structured data export, and a complete working application. For example, Business Central's database export documentation describes BACPAC exports and states that Microsoft does not support creating a working on-premises environment from the downloaded file. A database export is therefore not evidence of a ready-to-run replacement system.

Confirm supported formats, field definitions, attachment access, authorisation, export limits, and the arrangements after subscription termination. Have the supplier identify excluded data and any chargeable assistance in the proposal. Test with a second reviewer who did not prepare the export. Can that person trace the job without undocumented knowledge?

An exit test establishes retrievability. Moving into a replacement system is a separate project covered by the ERP data migration checklist.

Use evidence to make the decision

• Access failure: named owner, authorised fallback, and explicit stop conditions for each failure type.
• Recovery drill: submission uncertainty resolved, duplicate attempt tested, balances reconciled, and exceptions visible.
• Restoration: demonstrated procedure, authorised operator, integration restart controls, and business sign-off.
• Data exit: usable files, preserved relationships, readable attachments, and documented omissions.

Record each item as demonstrated, unresolved, or outside scope. Do not give an unresolved promise the same status as an observed test. Discuss the remaining gaps before selecting the subscription or customisation scope.

Bring this evidence to a discussion about manufacturing software development with Ploqy Technologies. Confirm hosting, recovery, integration, and support responsibilities in the proposed scope; this guide does not imply that Ploqy supplies a particular ERP platform or managed cloud service.