If you run Prophet 21 (P21) on-premises, the cloud conversation has probably started already. Maybe your Epicor account manager raised it at renewal. Maybe your CFO asked what the plan is. For almost every P21 customer the answer to "will we move?" is yes. The open questions are when, and what it will take.
Most distributors plan around Epicor's calendar. In our experience, the calendar that matters more is your own: what you've built around P21 over the years, and how long it takes to sort out before you go. This post covers what changes when P21 moves to the Epicor Cloud, where the work in a cloud migration tends to hide, and what you can do now to keep your options open.
Key Takeaways
- Epicor's direction for on-premises P21 is clear. New features go cloud-only after release 2028.1, and Active Support for on-premises ends June 30, 2029. After that, only Sustaining Support remains: maintenance and issue resolution, with no new enhancements. Staying where you are indefinitely isn't a realistic plan.
- Your lead time depends on your environment, not the calendar. A largely standard P21 setup can move quickly. One with years of custom jobs, reports, and integrations needs more runway.
- The work usually sits around P21, not inside it. Companion databases, scheduled SQL jobs, reporting servers, and file shares drive the effort far more than P21 screens and Crystal reports do.
- Some fixes are cheap before Epicor copies your database and expensive after. Sequence matters as much as effort.
- A few items are worth doing now regardless of timing, and some of them are risks on-premises today.
- Know your scope before you commit to a go-live date with Epicor, not after.
When Does On-Premises Prophet 21 Support End?
Epicor's final on-premises release of Prophet 21 is version 2028.1, tentatively scheduled for May 2028, and Active Support for it ends June 30, 2029. Here's the full schedule Epicor published in January 2026:
| Milestone | Date | What it means for you |
|---|---|---|
| Final on-premises release (2028.1) | Tentatively May 2028 | The last version with new features for on-premises customers |
| Active Support for 2028.1 ends | June 30, 2029 | Full support for the final on-premises release runs through this date |
| Sustaining Support begins | July 1, 2029 | Support continues for maintenance and issue resolution, without new enhancements |
Nothing forces you off on-premises P21 tomorrow. But every new capability, including the AI features Epicor is building into P21, lands in the cloud. The longer you wait, the further your system falls behind what your competitors on the cloud release can use.
The useful move is to count backward from the date you want to be live, not forward from today. And keep in mind that every other on-premises P21 customer is reading the same calendar. Expect demand for migration slots, and for experienced help, to bunch up as 2029 gets closer.
What Changes When Prophet 21 Moves to the Epicor Cloud?
In the Epicor Public Cloud, Epicor runs a dedicated P21 instance and database for you in its own Microsoft Azure environment. Epicor takes on infrastructure, security patching, and upgrades. The trade is that a managed environment runs under different rules than a SQL Server your team has controlled for years. None of this is unusual for an enterprise SaaS application, but each item changes how your team works.
| Area | On-premises today | In the Epicor Public Cloud |
|---|---|---|
| Database access | Full SQL access, ad hoc queries, scripted data fixes | No direct access. You read through a near-real-time, read-only replica. Writes go through the Prophet 21 API, which is licensed separately. Data fixes go through Epicor Support. |
| Custom SQL objects and jobs | Your team creates tables, procedures, scheduled SQL jobs, and triggers | You can't create objects or run scheduled SQL jobs against P21. Triggers don't function in Production. |
| Other databases on the server | Run alongside P21 | Only the P21 database is copied. Everything else stays behind. |
| Business rules, custom reports, portals | Run today | Not migrated or validated by Epicor. Rules that write directly to the database need to move to the API. |
| Reporting tools | SQL Server Reporting Services (SSRS), Excel, and BI tools connect straight to the database | SSRS runs against the replica, on a SQL Server you license and host. Crystal is being phased out in favor of Report Studio and Epicor Forms. |
| File shares and document links | Point to servers on your network | Carried over exactly as they are. Epicor doesn't repoint them to your new cloud environment. |
| Integrations | Any method: direct reads, direct writes, file drops | Reviewed one by one. File drops move to a cloud SFTP location, direct reads move to the replica, and direct writes move to the API. |
| Printing, fax, and forms | Local devices, VSIFax, Adobe Forms | Printers stay local, connected through the Epicor Edge Print Agent. For faxing solutions, check with your Epicor representative. Adobe Forms isn't supported. |
| Software on the server | Install what you need | Only Epicor-certified applications run on Epicor's servers. |
| Upgrades | On your schedule | Twice a year on Epicor's schedule, and Epicor is moving to a continuous (CI/CD) upgrade model. The Flex Option lets you defer for a fee. |
| Uptime | Your team's responsibility | Production carries a service level agreement (SLA) of about 99.7%. PLAY (the test environment) and the read-only replica aren't covered. |
Read down the right-hand column and a pattern shows up. Very little of it is about P21 itself. Most of it is about the things that connect to P21, run beside it, or reach into its database.
Why Your Environment Sets Your Migration Timeline
In our cloud readiness work, one pattern holds: the work sits around P21, not inside it. What a distributor has built beside P21 over ten or twenty years drives the effort, and none of it is visible from P21's screens. Here's where it tends to hide.
1. What lives inside P21 usually travels well
Custom portals, inquiry screens, and Crystal reports that read standard P21 data generally move with testing, not rebuilding. That's good news, and it's where many teams focus their worry.
They still need testing in PLAY. Queries now run in Epicor's data center rather than next to your users, so time your heaviest daily portals. And portals that filter on each user's default company or location come back empty if those defaults aren't set when users are provisioned.
2. Only the P21 database makes the trip
Epicor copies your P21 database. Every other database on that SQL Server stays behind: reporting databases, web store databases, integration staging databases. In our experience, companion databases are the most common hidden blocker, because everything that reads from or writes to them needs a new home.
This applies to you if: your P21 SQL Server holds more than one non-system database, or someone built a "reporting database" years ago.
3. Custom tables come across, but they freeze
Custom tables inside the P21 database move with it. The jobs that refresh them don't. From the day of the copy, those tables show data as of that day, and nothing warns you. Reports keep running and show stale numbers. Nobody gets an error.
This applies to you if: you have reports or portals built on tables your team created inside P21.
4. Scheduled SQL jobs stop running
Every scheduled SQL job that runs against P21 stops at cutover. That includes the nightly snapshot, the hourly status refresh, and the cleanup job somebody wrote in 2015.
There's often an upside. When a job's data comes entirely from P21, its output can frequently be rebuilt as a live report instead of a snapshot that's hours or days old.
5. Custom triggers won't work
Custom SQL triggers won't work in the Epicor Cloud. Any process that depends on one needs a different approach before go-live.
6. Look for the reporting server nobody mentioned
It's common to find a separate reporting server that reads P21, or a companion database, directly. It often isn't on anyone's migration list. It's also frequently the unknown consumer of custom tables that nobody can account for.
7. The replica is a convenience, not a guarantee
The read-only replica is how SSRS, Excel, Power BI, and many integrations will read your data. It's kept in sync continuously and typically runs seconds behind Production. But it isn't covered by the Production SLA, and every read-only consumer shares it. Anything time-critical should be identified early.
Every one of these is solvable. The point is that each adds lead time. A distributor with two business rules and no companion databases can move quickly. One with a decade of scheduled jobs and a separate reporting stack needs a longer runway, and needs to know that before picking a go-live date.
What to Fix Before Epicor Copies Your Database
Once you sign a Cloud Migration Statement of Work (SOW) with Epicor, the technical steps follow a consistent order:
That first copy is the line that matters. Before it, your team can change your own database directly. After it, data changes in the cloud go through Epicor Support. Some items that take hours on-premises take far longer once they're on the other side of that line.
A few examples of work that belongs before the copy:
- Document links. Attachments like vendor invoices, item images, and spec sheets often point to file shares on your network. Epicor carries those paths over exactly as they are. Left alone, users click a link in the cloud and find nothing at the other end.
- Screen customizations with images on local paths. These have been known to cause problems after migration and are best cleaned up first.
- History that lives outside P21. If years of snapshots or reporting history sit in a companion database, they're gone at cutover unless someone exports them.
- Files on servers you plan to retire. Custom forms and attachments stored on the old P21 servers need to be copied off before those servers go away.
This is why we recommend knowing your scope before committing to a go-live date. Discovering a sequencing problem in PLAY means some of the cheap options are already gone.
What to Do Now, Whatever Your Timing
These four pay off whether you go live next year or in 2029. The second is a risk on your current system today, cloud or no cloud.
1. Remove hard-coded SQL connections from business rules
Hard-coded SQL connections inside business rules should be removed, and the rules refactored to be cloud-compatible.
2. Move scheduled jobs off personal logins
Jobs that run under an individual's login stop the day that person's account is disabled. Reassign them to a service account now, while the person who set them up can still explain them.
3. Export history that lives outside P21
Snapshots and reporting history kept in a companion database don't come with you. If that history matters to finance or operations, export it and store it somewhere safe before anyone schedules a cutover.
4. Find out which reports people actually use
SSRS keeps a log of every report run, and most reporting tools keep something similar. Pulling it early shrinks the rebuild list more than any other single step. One catch: SSRS keeps only about 60 days of history by default, so pull it now or extend the retention setting. A report nobody has run in months doesn't need to move.
How to Choose Your Cloud Migration Window
There's no single right date. The right window depends on a handful of factors, and most distributors have a mix of both columns.
| Factor | Start earlier if... | You have more room if... |
|---|---|---|
| What's built around P21 | You have companion databases, many scheduled jobs, rules that write to SQL, or a separate reporting stack | You run a largely standard P21 setup with a modest number of custom reports |
| Integrations | Vendors read or write your database directly, or haven't confirmed API support | Your vendors already use the Prophet 21 API or exchange files |
| Your business calendar | Peak season, year-end close, or physical counts leave few safe cutover windows | You have several quiet windows across the year |
| Other projects | An acquisition, upgrade, or warehouse change is already in flight | The year ahead is relatively calm |
| How current you are | You're several P21 releases behind, so users face more change at once | You're on a recent release |
| Who knows your setup | The person who built your jobs and rules has left or is close to retiring | Your team understands and documents what's been built |
A note on budget timing. If you're setting 2027 budgets now, the work your team owns (remediation, validation, testing, and cutover support) belongs in its own line, separate from your Epicor subscription. It's the part of the move most often left out of the number. For the AI side of your 2027 plan, see What Epicor's Cognitive ERP Means for Prophet 21 Users.
The Throughline
Epicor has set the deadline. Your environment sets the lead time. The distributors who move smoothly won't necessarily be the ones who move first. They'll be the ones who knew what they had before they picked a date.
You don't need a go-live date to start. Find out what runs beside P21, clean up the risks you're carrying today, and decide your window from facts rather than from the calendar alone.
Frequently Asked Questions
Do we have to move Prophet 21 to the Epicor Cloud?
Not immediately. Release 2028.1, tentatively scheduled for May 2028, is the final on-premises release with new features. Active Support for it runs through June 30, 2029, and Sustaining Support begins July 1, 2029. After that, on-premises customers get maintenance and issue resolution but no new enhancements, so most distributors are planning when to move rather than whether.
Is Prophet 21 end of life?
No. Prophet 21 itself continues, and Epicor is developing it in the cloud. What ends is new feature development for the on-premises version after release 2028.1. On-premises customers then have Active Support through June 30, 2029, and Sustaining Support after that.
How long does a Prophet 21 cloud migration take?
It depends mostly on what's built around P21, not on P21 itself. Once your database is uploaded, Epicor typically builds your PLAY environment in about two weeks, and your team validates there before go-live. A largely standard setup can move quickly. An environment with companion databases, many scheduled jobs, and custom integrations needs more preparation, and that preparation is usually the longest part.
Will we have direct SQL access in the Epicor Cloud?
No. You read your data through a near-real-time, read-only replica that supports ODBC, Excel, Power BI, and SSRS. Anything that writes to P21 goes through the Prophet 21 API, which is licensed separately. Data fixes go through Epicor Support.
Will our custom business rules, reports, and portals migrate?
They come across with your database, but Epicor doesn't rewrite or validate them. Many will work with testing. Business rules that write directly to SQL need to be reworked to use the Prophet 21 API.
Do SQL triggers work in the Epicor Cloud?
Not in Production. A trigger may appear to work while you're testing in PLAY, but Epicor's position is that triggers don't function in the live cloud environment. Plan a different approach for any trigger-dependent process before go-live.
Can we keep using SSRS?
Yes, with changes. SSRS connects to the read-only replica, runs on a SQL Server you license and host, and uses SQL authentication. Reports that rely on companion databases, custom procedures, or writing data need to be rewritten.
Will our third-party integrations still work?
It depends on how each one connects today. File-based integrations move to a cloud SFTP location. Integrations that read the database can use the replica or OData. Anything that writes directly to the database has to move to the Prophet 21 API. Confirm each with the vendor rather than assuming.
What happens to document links and attachments?
Epicor carries them over exactly as they are, pointing to file shares on your network. If those paths aren't updated, users will find broken links in the cloud. Updating them in your on-premises database before Epicor takes its copy is far faster than fixing them afterward.
When should we start preparing?
Before you commit to a go-live date with Epicor. Knowing what runs beside P21 is what tells you how much lead time you need, and a few of the fixes are much cheaper before the database copy than after.
Planning Your Move to the Epicor Cloud?
We help industrial distributors running Prophet 21 work out what their move to the cloud will really involve, and when it makes sense to go. As the largest independent Prophet 21 professional services firm, with 20+ years of distribution expertise and an official Epicor partnership, we've seen what sits beside P21 in a lot of environments, and what it takes to bring it along.
If you'd like to talk through your timing, your environment, and what to do first, we'd be glad to have that conversation. It might be a quick call, or the start of a more formal readiness review before you commit to a date with Epicor.
Talk to an ExpertThis article reflects Epicor's published guidance and our own experience, and is current to the best of our knowledge as of October 2026. Epicor updates its cloud offering regularly, so confirm specifics with Epicor or our team before making decisions.
