Other ERPsFree checklistPDF, Excel, Word exportSage X3All Sage X3 and Sage 100 tools

Sage X3 Upgrade Path Checklist: Patches, Syracuse and Version Updates

This checklist covers applying a Sage X3 product update or moving from V11 to V12 and later releases such as 2024 R1 on your own servers. It focuses on what is specific to X3: the component stack, the product update procedure and Patch integration, folder revalidation, MongoDB backups and specific code.

0%

0 of 37 items complete

7 critical items still open - these are the highest-risk gaps.

Download checklist:

1. Plan

2. Backups

3. Apply in test

4. Regression test

5. Production cutover and rollback

Critical items are the ones that make a failed update recoverable: a full component inventory, verified backups including MongoDB, test folder first, compatible component versions and folder revalidation.

Get your upgrade plan reviewed

Send us your current component versions and target release and we will review the order of steps and the rollback plan.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Work through the five groups in order and do the whole list on a test environment refreshed from production before touching production. Record versions and dates against each item and export the completed list as the runbook for the production window. Items marked critical are the ones that make a failed update recoverable, so do not start a production window without them.

  • One owner per specific development for retesting.
  • Time each step in test to size the production window.
  • Keep the version inventory with the runbook.

Where this lives in Sage X3

Standard product updates follow the update procedure in the documentation for the target release, which also states the runtime, Syracuse, MongoDB and Elasticsearch versions it needs. Patch integration, under the development utilities for patches, loads patch files such as add-ons, partner patches and specific developments into the reference folder. Folder revalidation is run from folder management after the update so each folder picks up the new dictionary. Endpoints, web service pools and global settings are in Syracuse Administration, and the batch server is stopped and restarted from its own administration function.

Version differences and gotchas

The stack has several parts with their own versions: application, runtime, Syracuse web server with MongoDB and Elasticsearch, and the print server. Each release states which versions it supports, and an application update can require a newer runtime or Syracuse first. Revalidation can be long on production folders because heavy tables may be rebuilt, and nobody can be connected. Patches install processes in the reference folder, so specific code protected by activity codes must be checked, recompiled and retested after every update.

How to check the result

After the update, check the version screen and the server components show the target versions, the folder revalidation log has no errors, specific processes compile cleanly, and the batch server is running its scheduled tasks again. Then have business users run the regression list. Integrations are the most common late failure: call each SOAP publication and REST representation your partners use before reopening production.

Frequently Asked Questions

What is the Sage X3 upgrade path from V11?

V11 sites move to V12 and then onto the current V12-based releases named by year and release, such as 2024 R1 and later. Check the release notes and component compatibility for your target, update runtime and Syracuse as required, apply the application update in test, revalidate folders and retest specific code before production.

How do I upgrade Syracuse for Sage X3?

Use the Syracuse version certified for your target application release, plus any hotfixes Sage publishes for it. Back up the MongoDB database and your Syracuse configuration first, update in test, check endpoints, web service pools and certificates afterwards, and confirm users can log on before updating the application.

What is the difference between a product update and Patch integration in Sage X3?

A product update moves the whole stack to a new release: application, and often runtime, Syracuse and their database components, following the release's update procedure. Patch integration loads individual patch files, such as add-ons, partner patches or your own specific developments, into the reference folder. Both need folder revalidation and a retest of specific code afterwards.

How long does a Sage X3 version update take?

It depends on folder size, number of folders, specific code and how many releases you skip. Time each step during the test run, especially folder revalidation of large folders, and add regression testing and a rollback margin. Many sites plan a weekend window for production after one or two full test runs.

If you want your team to ask questions about Sage X3 data in plain English on your own servers, ready for the next update, we can set that up.

ArchRay builder
Design the on-prem AI stack for Sage X3 and Sage 100: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

AI on your ERP

Integrations

Software