On-premises Prophet 21 ends in 2029. Your customizations are the part nobody has planned for.

What Epicor has announced

The final on-premises release of Prophet 21 will be version 2028.1, in May 2028. Active support for on-premises installations, meaning security updates, critical patches and compliance updates, ends on June 30, 2029. From July 1, 2029 the product moves to sustaining support, which means no new releases and no further security or compliance patches.

This applies to every distributor running P21 outside Epicor’s cloud: self-hosted, in a private datacenter, on a perpetual license, or on your own servers at Azure or AWS. The route forward is Epicor’s cloud-hosted Prophet 21, and cloud does not offer the same freedom to customize that a server you control does. Anything you have built around the application has to be retooled to survive the move, and how hard that is depends on how long you have been running P21 and how much has accumulated around it.

Most migration guides stop there and hand you a checklist. This page is about the part the checklists skip.

The decision that has been getting made by default

Nobody decides to stay on an old version forever. The decision gets made one deferral at a time. There is a process that has to work: a billing file, a custom report, a script that touches the database directly. Nobody is sure what an upgrade will do to it, the person who wrote it is gone, and the safest choice this year has always been to wait.

The end of on-premises support removes that option. Waiting is no longer the safe choice, because the thing you were protecting will be running on an unsupported platform with no security patches. The risk that was being deferred is now on a calendar.

The cost of having deferred it is real. You passed on modules that would have helped. You stayed on infrastructure that got harder to support. And the gap between where you are and where you need to be kept growing, which makes the move larger and riskier than it had to be. None of that is a reason to feel bad about it. It is a reason to start with an honest inventory rather than a migration date.

What actually breaks in the move

• Direct database writes. Custom code that inserts or updates P21 tables directly, bypassing the application’s own logic. Cloud P21 does not permit this, and it is the most common thing I find.
• Legacy file processes. Scheduled scripts and flat-file transfers that depend on a specific server, folder or service account that will not exist afterwards.
• Anything that runs on the P21 server itself. A process that assumes it can sit on the same machine as the application will not make the trip.
• Reports built on old structures. Queries that assume fields and tables stay exactly as they were, or that reach into the database in ways the cloud does not expose.
• Undocumented dependencies. The customization nobody remembers until the day it stops. Every long-running P21 site has at least one.

How I approach it

1. Inventory. Find every custom process, integration, report and script that touches P21, including the ones nobody has thought about in years. This is the step most migration plans skip, and it is the one that decides whether the cutover is boring or catastrophic.
2. Sort by what the cloud allows. Decide what survives as it is, what needs adjusting, and what has to be rebuilt.
3. Rebuild on supported ground. Move the blockers to the P21 API, supported imports, and read access that works the same on-premises and in the cloud, so the rebuilt version runs today and after the migration.
4. Prove it before the cutover. Run old and new side by side until the results match. Migration day should hold no surprises about your custom code.

This work pairs naturally with a Fractional CTO engagement when the migration itself needs someone to carry it alongside your IT manager.

What you get on the other side

A move forced by a deadline can still be a good move. Once your data is in the cloud, it becomes far easier to let AI read it securely, which is the main obstacle to using AI on your own sales history today. And a process rebuilt on supported interfaces is one that can be understood, maintained and changed by someone other than the person who built it, which is the key-person problem that a decade-old customization usually is.

Questions about the end of on-premises Prophet 21