What Breaks When You Upgrade JAMIS Prime v8 to v9 – The Breaking-Change Index
A practical reference for JAMIS Prime administrators and consultants planning –
or recovering from – a v8 → v9 upgrade. Written June 2026, from a mechanical
diff of the data-access-class (DAC) catalogs behind the two versions.
TL;DR – A mechanical diff of the DAC catalogs behind JAMIS Prime v8 and
v9 finds 121 DACs removed, 683 fields removed from DACs that survive
– 804 mechanical break points – alongside 352 DACs added and 2,994
fields added. The breakage mechanics are simple: a removed DAC breaks
every Generic Inquiry, report, customization, or integration that references
it; a removed field breaks every artifact that selects it. That is why
a report that ran cleanly for years fails right after the upgrade. This
index is presence-only – it cannot see type changes, semantic renames, or
behavior changes, and it is not the official release-notes list. The
question that decides your upgrade is not “what changed in the product” –
it is “which of MY artifacts touch a break point.”
Why did my report break after the JAMIS Prime v9 upgrade?
Because something the report references no longer exists under the same name
on v9. Reports, Generic Inquiries (GIs), customizations, and integrations in
JAMIS Prime – like any product built on Acumatica’s xRP platform – do not own
their data layer. They reference it: every report cell, GI column, BQL query,
and field mapping points at a DAC (data access class) and its fields by
name. The artifact and the data layer are versioned separately – your report
definition survives the upgrade unchanged, but the data layer underneath it
moves. When v9 no longer carries a DAC or field your artifact names, the
reference dangles, and the artifact fails.
This is not something you did wrong, and it is rarely something the upgrade
process “missed.” It is the structural consequence of upgrading the platform
under artifacts that reference it by name – and it is enumerable in
advance, which is the point of this index.
What is a DAC, and why does removing one break reports and GIs?
A DAC (data access class) is the platform’s definition of a data entity –
roughly, a table plus its business logic surface. Everything you build on a
JAMIS Prime site hangs off DACs by name:
- A Generic Inquiry names DACs in its table list and fields in its result
columns, joins, filters, and parameters. - A report (Report Designer
.rpx) names DACs in its schema and fields in
its cells, groupings, and expressions. - A customization project names DACs and fields in its BQL queries, graph
extensions, and screen changes. - An integration names them through OData feeds (usually built on GIs) or
endpoint field mappings.
When a DAC is removed, every artifact that references it breaks – the GI
fails to load, the report fails to render, the customization fails to compile
or publish. When a field is removed from a surviving DAC, the breakage is
narrower but just as real: every artifact that selects that field breaks,
even though artifacts touching only the DAC’s other fields keep working.
How many breaking changes are there between JAMIS Prime v8 and v9?
804 mechanical break points, as measured by this catalog diff:
| Change | Count |
|---|---|
| DACs removed | 121 |
| Fields removed from surviving DACs | 683 |
| Mechanical break points (total) | 804 |
| DACs added (non-breaking) | 352 |
| Fields added (non-breaking) | 2,994 |
Three qualifiers, because the number is only useful if you know what it is:
- “Mechanical” means presence-only. Each break point is a DAC or field
present in the v8 catalog and absent in v9. The count says nothing about
type changes, renames, or behavior changes (see the honest-limits section
below). - The counts are tied to the specific builds compared. v8 and v9 both
ship update releases; a different update pairing could shift the numbers
slightly. Treat 804 as the shape of the change, not a constant of nature. - A break point is not the same as a broken artifact on your site. A
removed DAC your site never references costs you nothing; a single removed
field that your most-used invoice report selects costs you a support
incident. The 804 is the candidate list – your artifact inventory decides
which candidates are live.
What’s the difference between a removed DAC and a removed field?
A removed DAC is total breakage for the referencing artifact; a removed
field is selective breakage. The distinction matters for triage:
- Removed DAC (121 of them): any GI with the DAC in its table list, any
report with it in its schema, any customization querying it fails outright.
The artifact generally cannot run at all and must be redesigned against
whatever replaced the DAC – which a presence-only diff cannot tell you. - Removed field on a surviving DAC (683 of them): artifacts referencing
the DAC keep working unless they select, filter, group, join, or map on
the missing field. A GI loses a column or fails on a filter; a report fails
on a cell expression; an integration mapping silently has nothing to map.
These are usually quicker to fix – delete or re-point the reference – but
they are scattered and easy to miss until a user hits the one report that
selects the one field.
The same mechanics apply whether the change lives in a PX.* namespace (the
Acumatica platform base JAMIS Prime inherits) or a Jamis.* namespace (the
JAMIS-specific layer). The diff shows both kinds – most break points are in
the platform namespaces, with a meaningful JAMIS-side sweep on top.
What kinds of things were removed between v8 and v9?
Categories, not the full list – the shape is what helps you plan. As measured
by this diff:
- Legacy warehouse/inventory surface is the single biggest cluster. The
inventory namespace (PX.Objects.IN) loses dozens of DACs, including the
legacy barcode-scan header family (scan count / issue / receive / transfer /
warehouse-path), the WMS scan-log and storage-place DACs, and a large family
of internal document-release classes (cost-status, location/lot-serial
status, and history-update DACs). The setup DAC also loses
itsUseLegacyWMSflag. If your site built GIs or reports against legacy
WMS data, this cluster is where to look first. - Manufacturing scan and shift surface (
PX.Objects.AM): the
labor/material/move scan headers and a shift master DAC are removed, and
surviving manufacturing DACs lose a spread of shift- and labor-related
fields. - Platform feature removals: the image-recognition model DAC family
is removed outright, a HubSpot-sync notification DAC is gone, several
automation/notification DACs in the system-management namespace are
removed, and the platform feature-set DAC drops flags (including a
Google/Microsoft SSO toggle and an automation-module flag). - Legacy credit-card processing fields are stripped from sales orders and
invoices – authorization numbers, captured amounts, legacy-transaction
flags. The field names are consistent with a retirement of the older
CC-processing surface, though a presence-only diff cannot confirm the why. - Cross-module field sweeps:
TaxZoneIDandPayToParentdisappear from
vendor, customer, employee, and business-account DACs across AP, AR, CRM,
payroll, field-service – and from JAMIS’s own employee DACs. Presence-only
means we can’t say whether they were relocated or removed; either way, an
artifact selecting them on those DACs breaks. - Inquiry-result slimming: some inquiry result DACs lose large field
sets – the AP document inquiry result loses nearly ninety fields, an
inventory site-status summary loses more than fifty fields, nearly all of
them quantity fields. GIs
and reports built on inquiry results are disproportionately exposed. - GI designer metadata: the Generic Inquiry design tables themselves lose
aLastFlagfield across the board – relevant only if you have tooling or
customizations that read GI metadata, but breaking for exactly those. - JAMIS-side sweeps (
Jamis.JM.*): per-company mask and per-company ID
fields are removed across a set of workforce-management configuration DACs,
several timekeeping/expense DACs lose fields, and a small number of internal
JAMIS billing-rule and cost-maintenance DACs are removed.
What did JAMIS Prime v9 add?
Additions don’t break existing artifacts, but they tell you where the product
is going and where your next builds should target. The diff records 352 new
DACs and 2,994 new fields, including – by observed namespace names only,
flagged rather than asserted –
- new JAMIS-side namespaces whose names indicate AI, data-warehouse,
and SharePoint file-provider surface; - platform-side additions for GL anomaly detection, machine-learning
assisted Generic Inquiries, Microsoft Teams / Graph integration, a
Box storage provider, and data archiving; - hundreds of new fields across the sales-order, AR, cash-management,
purchasing, payroll, inventory, and manufacturing modules.
Heavy additive churn in a module is also a regression signal: even where
nothing was removed, a module that gained two or three hundred fields did not
stand still, and behavior changes (which this index cannot see) concentrate
where the surface moved most.
What does a mechanical breaking-change index miss?
Type changes, semantic renames, and behavior changes – a presence-only
diff cannot see any of them. That is why this section is the most important
one on the page: the index is generated mechanically from DAC catalog diffs,
and presence-only diffs have hard limits:
- Type changes are invisible. A field that survived but changed type can
still break an artifact – and won’t appear in the 804. - Semantic renames are invisible as renames. A renamed field shows up as
one removal plus one addition. The removal still breaks your artifact (it
references the old name), but the index cannot tell you what the
replacement is. “Removed” here strictly means “no longer present under that
name.” - Behavior changes are invisible entirely. A GI that still runs but now
returns different rows, a calculation that changed, a workflow that fires
differently – none of that is a catalog diff. These are the dangerous ones,
because they fail silently. Hard failures announce themselves; behavior
changes have to be caught by a regression pass that compares outputs, not
just checks that things load. - JAMIS-side metadata is reflection-derived. The
Jamis.*entries come
from reflecting over the product’s assemblies, not from vendor
documentation – they are flagged as observed, not asserted as authoritative. - This is not the official change list. JAMIS publishes release notes for
its versions; this index is an independent, mechanical complement to them,
not a substitute. Verify against official release notes before making
commitments – that is the rule we apply to ourselves, and it should be
yours too.
What the index is: the enumerable, name-level layer of the upgrade – the
part that can be computed in advance and cross-referenced against your site’s
artifacts mechanically, instead of discovered one broken report at a time.
Will the v8 to v9 upgrade break my integrations too?
The same mechanics apply – and integrations fail in the least visible
way. Three common surfaces:
- OData feeds built on Generic Inquiries break when the underlying GI
breaks: a removed DAC kills the GI, a removed field drops or errors a
column that a downstream consumer (a spreadsheet, a BI dataset, a sync job)
expects. - Endpoint field mappings that map a removed field have nothing to map.
Depending on the integration, that is an error at sync time or – worse – a
silently empty value flowing downstream. - Custom code (graph extensions, scheduled processes) referencing removed
DACs or fields fails at compile/publish time, which at least fails loudly.
The dangerous failure mode is the quiet one: an integration that keeps
running with a hole in it. Integration field mappings belong in the same
impact analysis as GIs and reports – they are references to DACs and fields
like everything else.
How do I find out which of MY reports and GIs will actually break?
Cross-reference your site’s artifact inventory against the break-point
index. It is a finite, mechanical job – not an estimate. The inputs:
- Your artifact inventory: every Generic Inquiry, every report
definition, every customization project, every integration field mapping
on the site – each one names the DACs and fields it touches. - The break-point index: the 804 removed DACs and fields.
The intersection is the answer: a concrete list of your artifacts that
reference a removed DAC (redesign needed) or select a removed field (re-point
or drop the reference), tiered by how much each artifact is actually used.
Everything not on the list is cleared for the name-level layer – and the
regression pass can then spend its time where it belongs: on outputs and
behavior, the part no index can clear in advance.
This per-site impact analysis is exactly the kind of fixed, bounded pass that
should happen before the upgrade is scheduled – and it is the natural first
deliverable when planning one. JAMIS Prime upgrades are delivered as a
managed service, which answers “who runs the upgrade” – but a managed
upgrade is not a managed regression of your artifacts. The custom GIs,
reports, and integrations on your site are yours, and knowing in advance
which of them touch a break point is your side of the upgrade.
Is this related to the Acumatica 2026 R2 migration?
Different event, same discipline – and for many sites, the same year.
JAMIS Prime is built on Acumatica’s xRP platform; the v8 → v9 jump is a
JAMIS-cadence event, while Acumatica’s 2026 R2 cycle (Classic UI removal, SQL
Server 2019 drop, legacy API sunset) is a platform-cadence event that JAMIS
sites inherit on JAMIS’s own timeline. Both reduce to the same two-step
method: enumerate what changes mechanically, then regression-test what the
mechanics can’t see. If you are planning around the platform cycle too, see
the companion guide: Preparing for the Acumatica 2026 R2 Forced Migration –
A Readiness Checklist – the
integration-API audit and the 6–8 week regression-pass reality described
there apply to a v8 → v9 pass as well.
And one upgrade-day specific: Report Designer is version-matched to the
site build, so after the upgrade your report authors need the build that
matches the new version – during a staged rollout that can mean maintaining
two installs. If your site is SSO-only (Entra ID / Okta / ADFS / FedRAMP),
report editing has a second, standing problem the upgrade does not fix –
covered in Acumatica Report Designer Doesn’t Work With SSO – Here’s Why,
and How to Fix It. An upgrade that forces you to
re-validate every report is the right moment to fix how reports get edited at
all.
What’s the honest status of this index?
Straight answer, because a number you can’t interrogate is worth nothing:
- The counts (121 / 683 / 804 / 352 / 2,994) are real, mechanical, and
reproducible – generated by a catalog diff over the DAC definitions of a
v8 build and a v9 build, as of June 2026. - The index is presence-only by construction. Type changes, semantic
renames, and behavior changes are out of scope and explicitly not claimed. - JAMIS-side metadata is reflection-derived – observed from the product,
flagged as such, not asserted as vendor documentation. - It is independent work, not a JAMIS publication. Verify against
official release notes before commitments; we do. - Counts are build-pair specific. Different v8/v9 update pairings could
shift them modestly; the categories and mechanics are stable. - This page describes categories rather than dumping all 804 entries; the
full namespace-organized index exists and drives the per-site impact
analysis described above.
FAQ
More questions are answered in the companion FAQ: JAMIS Prime v8 → v9 Breaking Changes – Frequently Asked Questions.
My report ran for years on v8 – why would the vendor break it?
Nothing was aimed at your report. Products evolve: legacy subsystems get
removed, fields get relocated, modules get rebuilt – and v9 rides a newer
platform base than v8. Your report breaking is the side effect of referencing,
by name, a surface the vendor no longer ships. The fix is mechanical once you
know which reference broke; the waste is discovering it in production instead
of on a list.
Is this the official JAMIS Prime change list?
No. It is an independent, mechanically generated index from DAC catalog
diffs, published as a planning aid. JAMIS’s release notes are the official
record – use this index to know where to look and what to inventory, and
verify against the official notes before commitments.
If a field was renamed rather than truly removed, is my report safe?
No – and this is worth being precise about. A rename appears in this index as
a removal (old name) plus an addition (new name). Your report references the
old name, so it breaks exactly as if the field were deleted. What the index
cannot do is tell you which addition is the replacement; that mapping takes a
human with release notes and the v9 schema.
Do the 352 added DACs and 2,994 added fields break anything?
By themselves, no – additions don’t invalidate existing references. Two
caveats: heavy additive churn marks the modules where behavior changes (which
no presence diff can see) are most likely; and anything you build after the
upgrade should target the v9 surface, so the additions define your new
baseline.
Can I just upgrade and fix whatever breaks?
You can, and the hard failures will indeed announce themselves – GIs that
error, reports that won’t render. What that plan misses is (a) the user-facing
window where your most-used artifacts are down while you triage, and (b) the
quiet failures: integration mappings flowing empty values and behavior changes
returning different numbers without erroring. Enumerate first, regression-test
second is cheaper than discover-in-production for any site with more than a
handful of artifacts.
The upgrade itself is managed by JAMIS – what’s left for me to do?
The vendor upgrades the product; nobody upgrades your artifacts. Custom GIs,
reports, customization projects, and integrations are site-specific by
definition – the managed upgrade moves the platform under them and the
regression of what you built is yours (or your consultant’s). The per-site
impact analysis is exactly that job, done before the upgrade instead of after.
Next step
If a v8 → v9 upgrade is ahead of you – or behind you, with breakage you’re
still triaging – the fastest path to certainty is a per-site impact
analysis: your GI, report, customization, and integration inventory
cross-referenced against the 804-point index, returned as a concrete,
tiered list of what needs attention before (or because of) the upgrade.
Get in touch for a per-site v8 → v9 impact analysis – a fixed, bounded pass
that replaces “wait and see what breaks” with a list.
Contact
A per-site v8 → v9 impact analysis – your artifact inventory cross-referenced against the 804-point index, returned as a concrete, tiered worklist.
Or email [email protected].