Preparing for the Acumatica 2026 R2 Forced Migration – A Readiness Checklist
A practical self-assessment for Acumatica and JAMIS Prime administrators ahead of
the expected ~October 2026 release. Written June 2026, while 2026 R2 is announced
but not yet shipped.
TL;DR – Acumatica 2026 R2 – expected ~early October 2026 per
Acumatica’s own patch-policy notice – is a forced-migration release, not a
feature release. It removes the ability to run Classic UI (Classic remains
supported only on pre-R2 versions), drops SQL Server 2019 (with SQL Server
2025 newly supported), and removes the legacy screen-based SOAP API while
sunsetting OData v3 in favor of contract-based REST and OData v4. A separate,
calendar-driven deadline compounds it: Chrome removes XSLT on November 17,
2026, which breaks Classic UI screens in Chromium browsers regardless of your
upgrade plans. With practitioners reporting 6–8 week regression test cycles
per upgrade, any site still on Classic screens, SQL 2019, or legacy APIs needs a
remediation plan now. This page is a self-assessment checklist across five
readiness dimensions – plus one optional AI item.
Is the Acumatica 2026 R2 upgrade mandatory?
Effectively, yes – if your site depends on Classic UI, SQL Server 2019, or
legacy APIs. Nobody flips a switch on your tenant, and pre-R2 versions keep
running. But three separate clocks make “do nothing” a plan that fails on its own:
- 2026 R2 removes the ability to run Classic UI. Classic remains supported
only on pre-R2 versions – so staying on Classic means staying off every future
release, permanently falling behind. - Acumatica’s patch policy changed in May 2026. Scheduled patches ended;
fixes now ship as critical-only on-demand patches delivered with the next
version. Sitting on an old version increasingly means sitting on unfixed issues. - Chrome removes XSLT on November 17, 2026 – and Classic UI screens depend on
XSLT. On that date, Classic screens break in Chromium-based browsers (Chrome,
Edge) even if you never upgrade. The only interim workaround is Firefox or a
pinned old browser build. This deadline sets the floor on any Classic-UI
migration schedule, independent of the R2 release itself.
So while the upgrade is not contractually “mandatory,” the combination of the R2
deprecations, the patch-policy change, and the browser deadline makes a managed
migration the only plan that doesn’t end in an unplanned one.
For ownership context only: Vista Equity Partners’ agreement to acquire Acumatica
was announced May 29, 2025. Everything on this page comes from what Acumatica
itself has published and from practitioner reports – not from speculation about
what new ownership might do.
When does Acumatica 2026 R2 come out?
Early October 2026 – expected, not yet confirmed by a GA announcement.
Acumatica’s community post updating the patch release policy (effective May 2026)
repeatedly dates 2026 R2 to early October 2026. As of June 2026:
- No published 2026 R2 feature list exists yet – only the date and the known
breaking changes, which Acumatica has announced in dated community posts (the
Classic UI deprecation announcement and FAQ, and the SQL Server 2019 deprecation
/ SQL Server 2025 support notice). - The date could move. Plan against “~October 2026,” and treat anything more
precise as unconfirmed until Acumatica says otherwise.
The practical implication: if a readiness pass plus a 6–8 week regression cycle has
to finish before you can take R2 – and before the November 17, 2026 browser
deadline – the planning window is now, not at GA.
What are the breaking changes in Acumatica 2026 R2?
Three, all announced by Acumatica in advance:
- Classic UI is removed. The ability to turn off Modern UI goes away in R2;
Classic remains supported only on pre-R2 versions. Custom.aspxscreens and
saved layouts built on Classic must be rebuilt for Modern UI. - SQL Server 2019 support is dropped. SQL 2019 still runs under 2026 R1, but
Acumatica has said DB-caused issues on 2019 won’t receive fixes. R2 requires
SQL Server 2022 or the newly supported SQL Server 2025. - The legacy screen-based SOAP API is being removed, and OData v3 is
sunsetting. Contract-based REST and OData v4 are the path forward. Endpoints
are versioned per release, so integrations should pin their endpoint version to
the instance version.
None of these is a surprise buried in release notes – each has its own dated
Acumatica community announcement. That is exactly why a readiness pass is
scopeable today, months before the release ships.
Will Classic UI still work after 2026 R2?
No – not on 2026 R2, and possibly not in your browser even before then.
On R2 itself, the ability to run Classic UI is removed. Acumatica’s deprecation
announcement and FAQ state that Classic remains supported only on pre-R2 versions.
Per the same announcement, business logic generally survives the move, but
UI-layer customizations need review or rebuild: fully custom screens convert from
.aspx to .ts/.html via the built-in “Convert to Modern UI” tool, and
customizations living in extension files must be re-created manually.
Two honest cautions from practitioner reports (as of mid-2026):
- The converter is real but produces incomplete output. Partner field reports
describe control-ID mismatches, broken grid-to-grid dependency logic, redundant
properties, and inaccurate layouts. Simple screens take hours to clean up;
complex screens can take days to reconstruct and validate. Budget for the
cleanup, not just the conversion. - Modern UI production-readiness has lagged the marketing. Practitioners
report having reverted screens to Classic on 2025 R2 due to issues – an escape
hatch that closes at R2. Third-party customization packages should be validated
for Modern UI before, not after, the upgrade.
And separately from R2: Chrome removes XSLT on November 17, 2026. Classic UI
screens depend on XSLT, so they break in Chromium browsers on that date regardless
of your upgrade plans. Acumatica has now published its fix plan (announced in the
community May 2026): a Classic-UI compatibility patch for 2025 R2 scheduled
June 30, 2026 and one for 2025 R1 scheduled July 3, 2026 – and no fix for
2024 R2 or earlier. Sites on those older versions must upgrade to 2025 R1+ (or
fall back to Firefox or a pinned old Chrome/Edge build) before the date.
Does Acumatica 2026 R2 support SQL Server 2019?
No. Acumatica’s deprecation notice is explicit: SQL Server 2019 support ends
at 2026 R2, and SQL Server 2025 is newly supported (alongside 2022). Two practical
points:
- SQL 2019 still runs under 2026 R1 – but without fixes for DB-caused issues.
It is tolerated, not supported. - For self-hosted and on-premises sites, the DB upgrade is a gating
prerequisite. You cannot take R2 on SQL 2019, so the SQL Server move
(2019 → 2022 or 2025) has to be scheduled, tested, and completed before the
ERP upgrade – it belongs at the front of the plan, not the end.
If you don’t know what SQL Server version sits under your instance (common when
hosting is outsourced), finding out is checklist item one.
What happens to SOAP and OData v3 integrations in 2026 R2?
They are on borrowed time, and R2 is when the clock runs out. The legacy
screen-based SOAP API is being removed, and OData v3 is sunsetting, with the old
OData URL format kept for backward compatibility likely only until R2 (per
community guidance as of 2025–2026 – treat the exact cutoff as something to verify
against Acumatica’s R2 release notes when they publish).
The forward path Acumatica recommends:
- Contract-based REST for transactional integrations, with the endpoint
version pinned to the instance version (endpoints are versioned per release). - OData v4 for query/reporting feeds.
The dangerous failure mode here is silence: an integration on screen-based SOAP or
OData v3 typically keeps working right up until the upgrade – then breaks in
production. The fix is an inventory now: every integration, what API it uses, and
a migration plan for anything on a legacy surface.
What changed with Acumatica’s patch policy in May 2026?
Scheduled patches ended. Effective May 2026, Acumatica moved to critical-only,
on-demand patches, with fixes otherwise delivered with the next version (2025 R1’s
final scheduled patch landed by May 26, 2026, per Acumatica’s policy update post).
The planning consequence: staying near-current matters more than it used to.
Under the old model, sitting a version or two behind still got you scheduled
fixes. Under the new model, the further behind you are, the more your open issues
wait for a version upgrade you haven’t planned. This is the quiet half of the
“forced migration” – the deprecations push you off old versions, and the patch
policy stops rewarding you for staying on them.
How do I prepare for Acumatica 2026 R2? – the readiness checklist
Work the five dimensions in order. Each is phrased so you can self-assess; an
“unknown” answer is a finding, not a pass – unknowns should become verify-this
tasks, never silent assumptions of safety.
1. SQL Server version audit (gating prerequisite)
- ☐ What SQL Server version runs under the instance? (If hosted, ask the host.)
- ☐ If 2019: schedule the move to SQL Server 2022 or 2025 before the R2
upgrade – it is a hard prerequisite, not a parallel task. - ☐ If unknown: confirming it is the first action item.
2. Classic-UI customization audit
- ☐ Inventory custom screens: which are custom
.aspx(Classic-pattern)
screens? Which customizations live in extension files (manual re-creation)? - ☐ Inventory saved layouts and user-facing Classic dependencies (including
training material built on Classic screens). - ☐ For each custom screen, assign a complexity tier – converter output needs
hours of cleanup on simple screens and days on complex ones. - ☐ Validate third-party customization packages for Modern UI now, while the
Classic escape hatch still exists.
3. Chrome XSLT calendar check (the floor on your schedule)
- ☐ Does anyone use Classic UI screens in Chrome or Edge? If yes, November 17,
2026 is your deadline even if you never upgrade. - ☐ On 2025 R1 or 2025 R2 with Classic UI: schedule the announced
compatibility patch (2025 R2: June 30, 2026; 2025 R1: July 3, 2026) and
verify Classic screens after applying it. - ☐ On 2024 R2 or earlier: no fix is announced – upgrading to 2025 R1+ is
the vendor path. Decide the interim posture if that won’t finish in time:
Firefox or a pinned old browser build.
4. Integration API audit
- ☐ Inventory every integration touching the site: what authenticates, what
reads, what writes – and which API each one uses. - ☐ Anything on screen-based SOAP or OData v3 needs a migration plan to
contract-based REST / OData v4 before R2. - ☐ Confirm endpoint versions are pinned to the instance version, so the next
upgrade doesn’t silently move the contract underneath them.
If one of those integrations is the link between your ERP and a second
operational system – a shop-floor/MES package, a CRM, an e-commerce
platform – the audit usually surfaces a larger pattern: nobody owns the
layer between the two systems. That gap, and the reconciliation layer that
closes it, is covered in our companion guide: When Your ERP and Your
Second System Don’t Talk – Owning the Data Layer Between
Them.
5. Regression test + remediation pass
- ☐ Plan a full regression of customizations and reports against a test
instance on the target version – staging first, never production-first. - ☐ Budget a 6–8 week cycle with real user involvement – that is the
practitioner-reported reality, not a worst case – and include remediation
time for issues the vendor classifies as “known issues.” - ☐ Count backward: a 6–8 week cycle finishing before an ~October 2026 release
window (and a November 17 browser deadline) means starting the readiness
work months earlier – i.e., roughly now.
Optional: AI-readiness Generic Inquiry review
- ☐ The AI Assistant reaches GA at R2 – read-only, metered, and able to answer
only over the Generic Inquiries you expose to it. If the organization
intends to use it, reviewing and designing GIs is a natural add-on to the
same readiness pass (see below).
Does the 2026 R2 migration affect JAMIS Prime sites?
Yes – with one important verification step. JAMIS Prime is built on
Acumatica’s xRP platform, so it inherits the platform-level pressures: the Classic
UI deprecation, the SQL Server 2019 drop, and the Chrome XSLT deadline all apply
to the underlying platform JAMIS ships on. JAMIS sites with older
Classic-pattern screen customizations face the same Modern-UI rebuild question as
any Acumatica site.
The hedge: JAMIS Prime ships on its own release cadence (v9 Update releases,
delivered as a managed upgrade service), and which Acumatica base version a
given JAMIS build tracks determines when each platform deadline actually lands for
that site. As of June 2026 there is no public JAMIS-specific 2026 R2 adoption
timeline – confirm against JAMIS’s own release notes before assuming a platform
date applies to your site on Acumatica’s schedule. The Chrome XSLT date is the
exception: it is browser-driven, so it applies to any site still rendering Classic
screens in Chromium on November 17, 2026, regardless of vendor timelines.
What happens to my reports and Report Designer at upgrade time?
Every major upgrade is a re-validation event for your reporting estate. Two
specifics worth planning for:
- Report Designer is version-matched to the site build. After the upgrade,
report authors need the Report Designer build that matches the new site version
– and during a staged rollout (test instance on R2, production on R1), that can
mean maintaining two installs. - Reports belong in the regression pass. Practitioner reports of upgrade
instability specifically include reports needing unexpected rework. Rendering
and regression-checking your critical reports on the target version is part of
checklist item 5, not an afterthought.
And if your site is SSO-only (Entra ID / Okta / ADFS / FedRAMP), you have a
second, independent reporting problem that an upgrade does not fix: Acumatica’s
desktop Report Designer cannot log into an SSO-only site at all. That limitation –
why it exists, and the approaches that work around it – is covered in our
companion guide: Acumatica Report Designer Doesn’t Work With SSO – Here’s Why,
and How to Fix It. If you are doing a readiness pass anyway,
it is the right moment to fix the report-editing workflow too.
For JAMIS Prime sites with a v8 → v9 upgrade on the same horizon, the
report-breakage side of that jump is enumerable in advance – see
What Breaks When You Upgrade JAMIS Prime v8 to v9 – The Breaking-Change
Index for the DAC-level break-point
index and how to find which of your reports and GIs touch it.
Should I prepare for the AI Assistant at the same time?
Only if you set expectations correctly – and then yes, cheaply. As of June
2026, Acumatica’s AI Assistant is in early access and is slated to reach GA at
2026 R2. Three facts to anchor on, all from Acumatica’s own FAQ:
- It is read-only – it answers questions; it does not act on or update records.
- It answers only over Generic Inquiries that an administrator has configured
and exposed – it sees what your GIs let it see, nothing more. - It is metered (pre-GA: ~5,000 AI Units/month, roughly 100 questions), with
post-GA pricing not yet disclosed. Don’t architect workflows around it until
pricing is known.
The practical preparation is therefore not “turn on AI” – it is GI design: if
the Assistant will only ever be as useful as the Generic Inquiries underneath it,
reviewing which GIs exist, what they expose, and what questions they can actually
answer is a small, concrete add-on to a readiness assessment.
What’s the honest status of everything on this page?
Straight answer, because dated claims are worth more than confident ones:
- 2026 R2 has not shipped. Its date (~early October 2026) and its breaking
changes are announced by Acumatica in dated community posts – the Classic UI
deprecation announcement and FAQ, the SQL Server 2019 deprecation / SQL Server
2025 support notice, and the patch-policy update. No full R2 feature list has
been published as of June 2026. - The patch-policy change is in effect (May 2026) – that part is shipped
reality, not expectation. - The Chrome XSLT date (November 17, 2026) is a browser-vendor deadline.
Acumatica has announced Classic-UI compatibility patches – for 2025 R2
scheduled June 30, 2026 and for 2025 R1 scheduled July 3, 2026 (announced,
not yet shipped as of this writing) – and has stated that 2024 R2 and
earlier versions get no fix. - The 6–8 week regression cycle and the converter-cleanup reality are
practitioner reports, not vendor commitments – which is exactly why they
belong in your budget. - This page will be updated when R2 reaches GA and when the feature list
publishes; the “as of June 2026” markers above are there so you can tell what
was known when.
FAQ
More questions are answered in the companion FAQ: Acumatica 2026 R2 Migration – Frequently Asked Questions.
Can I just stay on 2026 R1 and skip all this?
You can stay – Classic UI remains supported on pre-R2 versions – but you inherit
three costs: fixes now arrive mainly with new versions (patch policy, May 2026),
so issues on an old version increasingly wait; Chrome breaks Classic screens in
Chromium on November 17, 2026 regardless of your version; and every release you
skip makes the eventual migration larger. Staying put is a deferral with interest,
not an exemption.
Is the “Convert to Modern UI” tool enough on its own?
No. The tool is real and does the .aspx → .ts/.html conversion, but partner
field reports describe control-ID mismatches, broken grid dependencies, redundant
properties, and inaccurate layouts in its output. Plan per-screen cleanup –
hours for simple screens, days for complex ones – and manual re-creation for
customizations in extension files.
We’re hosted/SaaS – does the SQL Server item apply to us?
The prerequisite still exists; the question is who owns it. If Acumatica or a
hosting partner runs your database, confirm with them that the platform under your
tenant won’t be on SQL 2019 at R2. If you self-host, the 2019 → 2022/2025 move is
yours to schedule, and it gates the upgrade.
How do I know if any of our integrations use SOAP or OData v3?
Inventory, don’t assume. Check integration configuration for endpoint URLs
(screen-based SOAP and OData v3 URLs are distinguishable from contract-based REST
and OData v4 paths), check with the vendors of any packaged connectors, and treat
“nobody knows what this integration uses” as a blocking finding. This audit is
precisely the kind of thing a readiness assessment does in a fixed, bounded pass.
Does this affect JAMIS Prime on its own cadence?
Yes, with a verification step: JAMIS Prime runs on Acumatica’s xRP platform and
inherits the Classic UI / SQL 2019 / browser pressures, but it ships on its own
v9 Update cadence – confirm which Acumatica base your build tracks before mapping
the platform deadlines onto specific dates. The Chrome XSLT date applies to any
Classic screens rendered in Chromium, regardless of vendor timeline.
What does a professional readiness assessment add over this checklist?
The checklist tells you what to check; an assessment produces the verified
answers for your site: the actual SQL version, the actual custom-screen
inventory with complexity tiers, the actual integration-by-integration API audit,
and a sequenced remediation plan with the regression window booked against the
calendar. It converts unknowns into findings – and unknowns are where upgrade
projects fail.
Next step
If your site still runs Classic-UI customizations, SQL Server 2019, or
integrations you can’t confidently classify, the window for an orderly migration
is the next few months – the regression cycle alone is 6–8 weeks, and the
deadlines above don’t move for anyone’s project plan.
Get in touch for a per-site 2026 R2 readiness assessment – a fixed, bounded pass
that turns this checklist into verified findings and a sequenced plan.
Contact
A per-site 2026 R2 readiness assessment – a fixed, bounded pass that turns the checklist into verified findings and a sequenced plan.
Or email [email protected].