# ERP Patching Cadence: How Often Should You Patch? > Source: https://netray.co/erp-help/itm-erp-patching-cadence-how-often-to-patch > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Patch the ERP stack in layers on different clocks: operating system and database monthly or quarterly, ERP vendor cumulative updates quarterly or semi-annually, and security fixes on an emergency path measured in days. Test every patch in a sandbox refreshed from production, with a scripted regression and a tested rollback. ## Kind how-to ## System it-leadership ## Erp Any ERP and its infrastructure stack ## Module Change Management / Patching ## Query how often should we patch our ERP system ## Alternate Queries - ERP patching schedule best practice - ERP patch management process - how to patch ERP without downtime - ERP cumulative update vs hotfix policy ## Applies To Self-managed ERPs on Windows or Linux with SQL Server, Oracle or HANA: SAP, SyteLine, Infor LN, Dynamics, Epicor, JD Edwards. SaaS ERPs follow the vendor's release train. ## Steps ### Setting up an ERP patching program **Items:** - List every layer: hypervisor, operating system, database engine, application server or middleware, the ERP application and its add-ons, plus browsers, drivers and client tools. - Subscribe to vendor security bulletins for each layer and assign one person to triage new notices weekly. - Set a standing cadence: monthly OS and database security patches, quarterly ERP cumulative updates or service packs, and a documented emergency path for critical vulnerabilities. - Refresh a sandbox from production before each cycle so the test reflects real data volume, customisations and integrations. - Apply the patch to the sandbox and run a scripted regression covering order-to-cash, procure-to-pay, production reporting, month-end jobs, key custom reports and integrations. - Record the rollback plan before the change: a verified backup or snapshot, uninstall steps, and the decision point at which you abort. - Patch production in an agreed window, run the same smoke test, and keep the change under close monitoring for several days. - Close the ticket with evidence: patch ID, date, test results, who approved, and any follow-up issues. ## Sections ### Why one cadence does not fit every layer **Body:** The operating system and database engine ship security fixes on a frequent, predictable schedule, and they are the layers attackers target first. Delay these for a year and you accumulate known exploitable flaws. The ERP application itself changes more slowly and each cumulative update can alter behaviour, so it justifies fuller testing and a slower rhythm. A practical baseline for a manufacturer is monthly OS and database patching in a rolling window, quarterly or semi-annual ERP cumulative updates, and an annual review of whether the ERP version is still in vendor support. Many ERP vendors publish a lifecycle policy; running outside mainstream support removes access to security fixes entirely. Add an emergency path with a target timeline. For a critical remotely exploitable flaw in an internet-facing component, days rather than weeks is the usual expectation. For an internal-only issue with a compensating control, a longer timeline with documented risk acceptance is defensible. ### Testing that catches real breakage **Body:** ERP patches rarely break the standard screens; they break customisations, reports, integrations and performance. That is why the sandbox must be a recent copy of production with your custom code and your integration endpoints pointed at test targets. A pristine vendor demo system proves very little about your landscape. Maintain a regression script of twenty to forty business scenarios with expected results, owned by the process owners. Include at least one large report, one batch job such as MRP or cost roll-up, one inbound and one outbound integration message, and a print or document generation step. Record timings so you notice a performance regression even when the function still works. Automate what you can. Even a modest set of scripted API calls or UI tests that run after every patch turns a two-day manual exercise into a repeatable check, and the saved results double as audit evidence. **Code:** Patch ticket checklist (copy into your change record) - Layer and patch ID: - Vendor advisory / CVE reference: - Sandbox refreshed on: - Regression result (pass/fail, link): - Rollback method verified (backup/snapshot id): - Window and approver: - Post-patch smoke test result: - Follow-up issues: ### Windows, downtime and rollback **Body:** Agree maintenance windows with the plants. A manufacturer running three shifts may have only a few hours on Sunday, which shapes how much you can combine in one change. Prefer smaller, more frequent changes over rare large ones, because the blast radius and the rollback are both simpler. Reduce downtime with architecture rather than heroics: patch the passive node of a cluster first, use rolling updates across application servers behind a load balancer, and keep the database patch separate from the application upgrade. Each separation makes failures easier to attribute. Write the rollback before the change, not during an incident. A virtual machine snapshot is quick but does not protect a database whose schema was upgraded and then received new transactions. Define the point after which rollback means restore plus re-keying, and make the go or no-go decision before that point. ### Governance and evidence **Body:** Tie patching to your change management process so each production change has an approver, a test record and a back-out plan. For regulated or customer-audited environments, a monthly report of patch compliance by layer, and a list of exceptions with owners and expiry dates, answers most questions before they are asked. Track exceptions explicitly. Sometimes a patch cannot be applied because a vendor add-on is not certified for it. Record the reason, the compensating control such as network isolation, and a date to revisit. Open-ended exceptions are the difference between a managed risk and a forgotten one. Review the programme annually: mean time to patch critical issues, number of emergency changes, and how many patches caused incidents. Use those figures to adjust windows and test scope. ## Pitfalls - Patching production first because the sandbox is stale or unavailable, then discovering custom code failures live. - Treating the ERP as the only layer and leaving the database, hypervisor and drivers unpatched for years. - Applying a database patch and an ERP upgrade together, so a failure cannot be attributed. - Relying on a VM snapshot as the only rollback after the database has accepted new transactions. - No named owner for vendor security bulletins, so critical notices sit in a shared mailbox. - Running an ERP version past vendor support with no documented risk acceptance. ## Ai Angle An assistant such as SyteRay for SyteLine can help assess a patch's impact before testing by listing the customisations, custom reports and event handlers that touch the changed areas, and by summarising release notes against your configuration. It supports the analysis and test planning; the patch decision, change approval and production deployment remain with your team. ## Faq ### How often should an ERP be patched? **Answer:** Patch operating system and database security updates monthly, and apply ERP vendor cumulative updates or service packs quarterly to semi-annually, depending on release volume and your testing capacity. Keep an emergency path for critical vulnerabilities measured in days. Run only versions that are still in vendor support. ### Do we need to patch the ERP if it is not on the internet? **Answer:** Yes, though the urgency differs. Internal systems are still exposed to compromised workstations, phishing footholds and insider misuse. Network isolation lowers risk and can justify a longer timeline for some fixes, but it does not remove the need for a regular cadence. ### What should the sandbox contain? **Answer:** A recent copy of production data with sensitive fields masked if policy requires, your full set of customisations and custom reports, and integration endpoints pointed at test targets. Without realistic data volumes and customisations, performance and compatibility problems will not show up. ### Can we skip ERP updates and only patch security? **Answer:** For a while, yes, but vendors typically bundle security fixes into cumulative updates and eventually retire old versions. Skipping several updates makes the eventual jump larger and riskier. Smaller regular steps cost less in total than occasional large upgrades. ## Search terms ERP patching schedule, ERP patch management, how often to patch ERP, ERP cumulative update policy, ERP security patching, ERP change management patch, ERP sandbox refresh, ERP maintenance window, ERP regression test script, ERP vendor support lifecycle --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json