A cash-flow-critical billing process that no longer depends on one person.
Wholesale distributor. Operator application on P21 data with rule checking. About 4 weeks.
Read the full storySolution
When an old customization is the reason you cannot upgrade Prophet 21.
Many distributors stay on an old version of Prophet 21, or put off a move to the cloud, because a custom process might not survive the change. The way out is to identify what depends on the old environment, rebuild those pieces on interfaces P21 supports, and prove they work before the upgrade, so the upgrade becomes a scheduled event instead of a risk.
The decision that gets 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 the upgrade will do to it, the person who wrote it is gone, and the safest choice this year is to wait.
The cost of waiting is easy to miss because it does not show up on an invoice. You pass on new modules that would help. You stay on infrastructure that gets harder to support. And the gap between where you are and where you need to be grows, which makes the eventual move larger and riskier than it had to be.
What usually blocks the move
- Direct database writes. Custom code that inserts or updates P21 tables directly, bypassing the application’s own logic.
- Legacy file processes. Scheduled scripts and flat-file transfers that depend on a specific server, folder, or account.
- Reports built on old structures. Queries that assume fields and tables stay exactly as they were.
- Anything that needs the server itself. Cloud P21 draws tighter boundaries than an on-prem server you control. A process that assumes it can run on the P21 server will not make the trip.
- Undocumented dependencies. The customization nobody remembers until it stops.
How I approach it
- Inventory. Find every custom process, integration, report, and script that touches P21, including the ones nobody has thought about in years.
- Sort by risk. Decide what will survive as it is, what needs adjusting, and what has to be rebuilt.
- Rebuild on supported ground. Move the blockers to the P21 API, supported imports, and read access that works on-prem and in the cloud.
- Prove it before the cutover. Run old and new side by side until the results match, so upgrade day holds no surprises.
This work pairs naturally with a Fractional CTO engagement when the upgrade itself needs someone to carry it alongside your IT manager.
Related work
Questions
Do you perform the P21 upgrade or migration itself?
Epicor or your implementation partner handles the upgrade mechanics. I make sure your custom processes are ready for it, and I can lead the project on your side.
We do not know what customizations we have. Is that a problem?
It is the normal starting point. Finding them is step one.
Request a call back
Is one process holding your whole upgrade hostage?
Let's look at it.
- One conversation, no obligation. There is no charge and no pitch.
- A plain answer. If it is not feasible, or I am not the right fit, I will say so.
- The first 30 days are guaranteed. If you are not satisfied and I cannot make it right, in your opinion, you get your money back.