Acumatica 2026 R2 Readiness Assessment
A fixed, per-site engagement that turns the 2026 R2 forced migration from a
list of announcements into verified findings and a sequenced plan – for
Acumatica and JAMIS Prime sites. Written June 2026, while 2026 R2 is announced
but not yet shipped.
The offer in one sentence – Acumatica 2026 R2 (expected ~early
October 2026) removes Classic UI, drops SQL Server 2019, and retires the
screen-based SOAP API while sunsetting OData v3 – and practitioners report
6–8 week regression cycles per upgrade. This assessment works your
specific site through five SOW line-items, applies a mechanical
breaking-change exposure scan, snapshots your critical Generic Inquiry
outputs for before/after regression proof, and hands you a sequenced
upgrade runbook with the calendar math already done.
Why a readiness pass, and why now
Three clocks are already running, none of them yours:
- 2026 R2 removes the ability to run Classic UI – Classic stays supported
only on pre-R2 versions. - Acumatica’s patch policy changed in May 2026 – scheduled patches ended;
fixes now ship mainly with the next version, so staying behind means
sitting on unfixed issues. - Chrome removes XSLT on November 17, 2026 – Classic UI screens break in
Chromium browsers on that date regardless of your upgrade plans.
Count backward from an ~October release window through a 6–8 week regression
cycle and the planning window is now, not at GA. The full self-assessment
version of this argument is free, in our companion guide:
Preparing for the Acumatica 2026 R2 Forced Migration – A Readiness
Checklist. This page is the
done-for-you version: the checklist run against your site, with evidence.
The five SOW line-items
Every line-item produces findings, not opinions – and an unknown answer
becomes a verify-this audit task, never a silent assumption of safety.
1. SQL Server platform audit (the gating prerequisite)
What version actually runs under your instance – including the
hosted-and-nobody-knows case. If it is 2019, the move to SQL Server 2022 or
2025 is a hard prerequisite that must be scheduled, tested, and completed
before the ERP upgrade; the assessment sequences it at the front of the
plan, where it belongs.
2. Classic-UI customization audit (complexity-tiered)
A per-screen inventory: which screens are custom Classic-pattern .aspx,
which customizations live in extension files (manual re-creation), which saved
layouts and training materials depend on Classic. Each custom screen gets a
complexity tier, because partner field reports are consistent: the built-in
converter is real but its output needs hours of cleanup on simple screens and
days on complex ones. The Chrome XSLT date is checked against your actual
browser estate, since it can land before your upgrade does.
3. Integration API audit (SOAP / OData v3 exposure)
Every integration touching the site, inventoried: what authenticates, what
reads, what writes, and which API surface each one uses. Anything on the
screen-based SOAP API or OData v3 gets a migration plan to contract-based
REST / OData v4, with endpoint versions pinned to the instance version. The
dangerous failure mode is silence – a legacy integration keeps working right
up until the upgrade, then breaks in production. The audit exists to make
that impossible to be surprised by.
4. Reporting & GI regression pass – with output snapshots
Reports and Generic Inquiries are a known casualty of major upgrades. This
line-item plans the regression pass and arms it with tooling: a GI output
regression snapshot – a machine-captured record of each critical Generic
Inquiry’s actual output (via OData, on a quiesced test instance) taken
before the upgrade, then mechanically diffed against the same pull after.
“We think the reports survived” becomes a diffable fact. Honest status: the
snapshot/diff tooling is built and has been exercised live against a vanilla
sandbox; your site’s first snapshot run is part of the engagement, on your
test instance.
5. AI-readiness GI review (optional attach)
Acumatica’s AI Assistant is slated to reach GA at R2 – read-only, metered,
and able to answer only over the Generic Inquiries you expose to it. If
your organization intends to use it, the same assessment pass reviews which
GIs exist, what they expose, and what questions they can actually answer.
Cheap to add while we are already in your GI estate; pointless to do anywhere
else.
The breaking-change exposure scan (the methodology)
Announcements tell you what the platform changes. They do not tell you which
of your artifacts touch a change. Our method closes that gap mechanically:
diff the data-access-class (DAC) catalogs behind two versions, enumerate every
removed DAC and every removed field, then cross your site’s artifact inventory
(GIs, reports, customizations, integrations) against the break-point list.
The methodology is proven at scale on the JAMIS Prime v8 → v9 jump: a
mechanical, presence-only catalog diff finding 804 break points (121 DACs
removed, 683 fields removed from surviving DACs), as measured against the
specific builds compared – see the v8→v9 Breaking-Change
Index. Honest limits, stated
plainly: a presence-only diff cannot see type changes, semantic renames, or
behavior changes, and it is not the vendor’s official change list. For 2026
R2, the same scan runs the moment an R2 build’s catalog is available;
until then, the v8→v9 index is the demonstration that the method works and
the readiness pass proceeds on Acumatica’s announced changes.
What you walk away with
- A findings report per line-item: verified facts about your site, with
every unknown converted into a named audit task. - An exposure list: which of your artifacts are candidates to break, and
why – mechanically derived where a catalog diff exists, announcement-driven
where it doesn’t yet. - Baseline GI output snapshots for your critical inquiries, filed as the
before-state for post-upgrade regression proof. - A sequenced upgrade runbook: prerequisites first (SQL Server), the
remediation work tiered by complexity, the integration migrations, the
regression window booked against the real calendar (release window, browser
deadline, your blackout dates), and explicit go/no-go checkpoints.
What this page will not claim (as of June 2026)
- 2026 R2 has not shipped. Its date (~early October 2026) and breaking
changes are announced by Acumatica in dated community posts; no full R2
feature list has been published. Nobody – including us – has performed a
2026 R2 upgrade, because the release does not exist yet. That is exactly
why the readiness work is what is sellable and useful today. - The 6–8 week regression cycle is a practitioner-reported figure, not a
vendor commitment – which is why it belongs in your budget. - JAMIS Prime sites inherit the platform pressures via Acumatica’s xRP
platform, but JAMIS ships on its own release cadence – which Acumatica base
your build tracks is a verification step inside the assessment, not an
assumption.
Next step
Book a consultation
or email [email protected]
– a readiness assessment is a fixed, bounded pass, and the deadlines above do
not move for anyone’s project plan.
Contact
A per-site 2026 R2 readiness assessment – bounded scope, verified findings, a sequenced plan.
Or email [email protected].