What a Prophet 21 upgrade does to your reporting
The upgrade rarely breaks the ERP. It breaks what you built on top of it — and it does so quietly, because a report that reads the wrong rows still returns a number.
Three different projects get called “the P21 upgrade”, and they are not the same size, do not carry the same risk, and do not break the same things. Before anyone estimates the reporting work, it is worth being precise about which one is actually happening — the answer changes whether the reporting layer needs a repair, a rebuild, or nothing at all.
Scope, stated up front. This page is about the reporting and integration layer around Prophet 21, not about running the upgrade. The upgrade itself is the platform owner’s project, run with Epicor or a reseller, and it should stay that way. What follows is the part that usually has no owner: the custom reports, dashboards, indexes, extracts and integrations that were built against a schema somebody else is about to change.
Three things called an upgrade
A version upgrade — same product, newer release
The ordinary case. The schema is still the vendor’s and still recognisably itself, but tables gain columns, views get redefined, and objects that were never documented in the first place move without announcement. Nothing here is dramatic on its own. The damage is cumulative and it lands entirely on things that read the database directly.
The reporting risk is proportional to how far behind you are, because every skipped release’s schema changes arrive in the same window. A shop two releases behind is doing a repair. A shop that has not upgraded since the desktop client was current is doing an archaeology project first.
The desktop-to-web transition — same product, different client
This one is largely historical now and is still the reason a lot of P21 reporting is in the state it is in. Epicor stopped adding features to the Prophet 21 desktop application at the Spring 2021 release, moved new development to the web application, and ended desktop fixes on 30 November 2022. Dates and versions are in the sources below; re-check them against Epicor before planning around them.
What that did to reporting was not subtle: anything whose delivery mechanism was the desktop client — a report launched from a menu, a print job wired to a workstation, a tool that assumed a Windows session — needed a new home, whether or not the query underneath it was still correct. A good deal of it never got one. It got a person running it manually instead, and that person is now the documentation.
If you are still on a desktop-era version in 2026, the reporting question is downstream of a support question, and the support question has the date on it.
Replacing Prophet 21 with Epicor Kinetic — a different product
Not an upgrade. Prophet 21 and Kinetic are separate products with separate code bases and separate roadmaps, built for different industries — Prophet 21 for wholesale distribution, Kinetic for discrete and mixed-mode manufacturing. Moving between them is a re-implementation.
For the reporting layer that means the honest estimate is none of it comes across. Not the queries, not the indexes, not the extracts, not the mappings. The business logic survives — what a metric is supposed to mean, which rows should count, which exceptions are real — and that is worth writing down properly before the old system goes away, because it is the only asset that transfers.
When a proposal calls this an upgrade, that is worth a direct question. The word is doing a lot of work.
What actually breaks
In every one of the three cases the ERP comes back up and the standard screens work. The failures are in the layer nobody in the upgrade project owns, and they share a characteristic that makes them expensive: they do not raise errors.
| What it is | How it fails | How you find out |
|---|---|---|
| Queries reading vendor tables directly | A column changes meaning, or a row that used to be excluded starts arriving. The query still runs. | Somebody notices the number moved and cannot explain why — typically a month later, at close. |
| Custom indexes on vendor tables | Dropped or not carried forward. Nothing is obliged to preserve an object the vendor did not ship. | The long-range report starts timing out again. Same query, same plan shape as before it was ever fixed. |
| Reports bound to the old client | The delivery mechanism disappears while the query stays valid. | Immediately, and this is the good case — a visible break gets fixed. |
| Integrations bound to table shape | An added column or a changed nullability breaks a load, or worse, does not break it and writes something subtly wrong. | The load that fails is found the same day. The one that succeeds incorrectly is found by reconciliation, if there is one. |
| Anything reading an undocumented view | Redefined upstream. The view still exists and still returns rows. | Usually never, directly. It surfaces as two reports disagreeing. |
This is the same failure mode described in the four traps in P21 reporting, arriving by a different route. There, the wrong rows were counted because the data model was misread. Here, the model was read correctly and then changed underneath. The symptom is identical — a plausible number, moving in a believable direction, built on rows that should not be in it — and so is the reason it survives so long: nothing in the system objects.
The inventory, and the baseline you cannot go back for
Two artefacts are worth producing before the upgrade window opens, and both become impossible to produce properly afterwards.
The dependency inventory is the list of everything outside the ERP that reads the ERP: reports, dashboards, scheduled extracts, integrations, spreadsheets with live connections, and the workstation scripts that were never called integrations because one person wrote them. For each one, what it reads and who notices when it is wrong. Most of this list does not exist anywhere when the question is first asked, and assembling it is frequently the most useful part of the exercise regardless of the upgrade — it is the first time anyone has written down what the business actually depends on.
The performance baseline is runtime and logical reads for the reports that matter, captured on the current production system. Logical reads rather than wall-clock time, for the reasons set out in the SQL Server method page: runtime moves with cache state and load, reads do not. This is the measurement that cannot be recovered. Once the window closes the old state is gone, and every later argument about whether the upgrade made reporting slower becomes a disagreement about how it used to feel.
Index definitions belong in source control, not only in the database. An index applied to a vendor table during a tuning engagement is invisible to the upgrade and to whoever runs it. If the only record of it is the database it was applied to, the upgrade is the event that silently removes a fix somebody paid for — and the report that starts timing out afterwards looks like a new problem. Keep the definition, the date, and the reason it exists.
Worth measuring if you run this
No percentages are published on this page, for the same reason they are absent from the rest of this site: a figure is only worth quoting if somebody captured the before state, and in upgrade work almost nobody did. These are the measurements that make the reporting side of an upgrade assessable rather than anecdotal.
- Report runtime and logical reads for the reports that matter, captured before the window and again after — the same reports, the same parameters, both times.
- Count of items in the dependency inventory, and how many of them nobody could name an owner for.
- Custom indexes present before the upgrade, versus present after.
- Number of reports that returned a different figure after the upgrade for the same period, and how many of those differences were correct.
- Elapsed time from the window closing to the last piece of reporting being confirmed working, rather than assumed working.
What this is not
This is not upgrade delivery, migration planning, or ERP selection. It does not include running the upgrade, sizing the environment, or negotiating with the vendor. Full re-implementation is a different kind of engagement and there are firms that specialise in it — that boundary is stated on the P21 page as well, and it has not moved.
What it is: the inventory, the baseline, and the repair of the reporting and integration layer either side of somebody else’s window.
Frequently asked questions
Do you run the upgrade itself?
No. The upgrade is the platform owner’s project, run with Epicor or a reseller. This is the reporting and integration layer around it — the inventory of what depends on the schema, the baseline captured before the window, and the repairs afterwards. Those are separate jobs and it is better for you if they are separate people.
Is moving from Prophet 21 to Kinetic an upgrade?
No. They are separate products with separate code bases and separate roadmaps, aimed at different industries — Prophet 21 at wholesale distribution, Kinetic at discrete and mixed-mode manufacturing. Moving between them is a re-implementation, and none of your reporting comes across. Anyone describing it as an upgrade is either being loose with the word or has not looked at the schema.
Will our custom indexes survive?
Assume not, and plan to re-apply them. An index added to a vendor table is not part of the vendor’s shipped schema, so nothing in the upgrade is obliged to preserve it. The failure is quiet: the report still returns, it just reads the whole history table again. Keep the index definitions in source control with the reason each one exists, not only in the database.
When should the baseline be captured?
Before the upgrade window opens, on the current production system. Runtime and logical reads for the reports that matter cannot be recovered afterwards — once the window closes, the old state is gone and every performance argument becomes a memory of how it used to feel.
We are several versions behind. Is that a reporting problem or a support problem?
Both, and the support problem is the one with a date on it. Being unsupported does not make a report wrong today; it makes the eventual upgrade larger, because the schema changes accumulate and arrive together. The reporting work is the same either way — inventory what depends on the schema, baseline it, and expect the gap between your version and the current one to be roughly the size of the repair.
Sources, and how dated these are
The vendor-specific claims on this page are dated by nature and are stated here with their source so you can re-check rather than trust the page — the same convention used on the Claude articles on this site, and for the same reason: product timelines move, and a page quoted back as current two years later is worse than no page.
- Desktop feature freeze and end of fixes. The Spring 2021 release (Prophet 21 2021.1) is described as the final desktop version to receive new features, with new development moving to the web application, and no further desktop fixes after 30 November 2022 — Echopath, December 2020. That is a third-party summary of an Epicor announcement, not Epicor’s own page; treat the dates as a starting point and confirm them with your account team.
- Prophet 21 and Kinetic as separate products. Separate code bases and roadmaps, aimed at distribution and at discrete/mixed-mode manufacturing respectively — ERP Research product comparison, and Epicor’s own product pages for each.
- Everything else here — what breaks, what to inventory, what to measure — is method rather than vendor fact, and does not go stale on a release schedule.
Vendor claims on this page last checked 18 August 2026.
Related
- Epicor P21 and Kinetic reporting and integration — the main platform page, and the four data-model traps that make P21 reports quietly wrong. Start there if the question is which rows count.
- SQL Server performance for ERP reporting — why logical reads are the honest baseline measure, and what applying an index to a vendor schema actually costs.
- Why your ERP report is fast on Today and times out on month-to-date — the worked example of the index that an upgrade is most likely to remove.
- Operations modernization — including ERP carve-out and cutover, which is the re-implementation shape rather than the upgrade one.
- Case studies — anonymised, with the measurement discipline this page argues for.
Upgrade window on the calendar?
The inventory and the baseline are worth doing before it opens, and they are cheap compared with reconstructing them afterwards. Thirty minutes to work out which of the three projects you are actually doing, and what it puts at risk.