Systems and records
Epicor Prophet 21: archiving old orders before an upgrade
By SourceX Editorial · Updated
Short answer
Archiving old orders in Epicor Prophet 21 before an upgrade means exporting closed order history to storage you control before any purge runs. The rule: archive first, purge second, and never purge records you cannot rebuild from the archive, including notes, attachments and the links between orders, invoices and returns.
Key takeaways
- A purge deletes history from the live Prophet 21 database; an archive copies it somewhere you control before anything is removed.
- Export order headers, lines, notes, invoices, returns and the customer and item masters together so the keys still join.
- Verify record counts and sample orders before the purge runs, not during the upgrade window.
- Keep the archive readable without Prophet 21, in open formats with a data dictionary.
- Order history that records substitutions, exceptions and price decisions can matter beyond retention, so assess it before deleting anything.
Purge or archive: which comes first in Prophet 21?#
Archiving comes first in Prophet 21, because a purge removes order history from the live database and the archive is the only readable copy left afterward. Distributors often run a history purge before an upgrade to shrink the database, and that is a reasonable goal. The mistake is purging before anyone has exported and checked what is being removed.
A purge is not undone from inside the application. Once closed orders, their lines and their notes are gone, the fallback is a database backup, which needs a compatible server and often a matching application version to read. Treat the backup as insurance and the archive as the working copy.
| Order history | Archive first? | Purge afterward? |
|---|---|---|
| Closed orders your team still looks up in daily work | Not yet; they stay live | No |
| Older closed orders, fully invoiced and paid | Yes, with lines, notes and invoices | Only after the export is verified |
| Orders tied to open returns, credits or disputes | Yes | No, keep live until resolved |
| Orders feeding open rebate, contract pricing or vendor claims | Yes | No, until finance signs off |
| Quotes that never converted to orders | Yes, if sales studies win and loss patterns | Usually |
| Logs, temporary tables and print queues | Rarely | Yes, following Epicor or partner guidance |
Why do distributors purge P21 history before an upgrade?#
Database size is the usual reason distributors purge Prophet 21 history before an upgrade. A large database makes conversion runs, test restores and backups slower, and every test cycle in an upgrade project repeats those steps. If the upgrade also moves the system to hosted or cloud infrastructure, storage and performance become line items someone has to defend.
The purge cutoff is often set by default rather than by decision. A partner proposes a date, IT accepts it, and nobody asks sales, purchasing or finance which older orders they still open. Before agreeing to a cutoff, ask each group to name the reports, lookups and disputes that reach back past it.
Size also hides in places a purge does not touch. Attachments, audit tables and custom tables added by past consultants can grow faster than order history, so check where the space actually goes before deciding that old orders are the problem.
What to export first, and in what order#
The first export should capture order history as a connected set: headers, lines, notes, invoices, returns and the masters that give their codes meaning. An order line without its header, or a credit memo without the order it reverses, loses most of what made it worth keeping.
Masters belong in the archive because codes drift. Customers get merged, items are superseded by new part numbers and branches close. A transaction archive without the masters as they stood on export day will not join back to anything a year later.
- Closed order headers and lines: dates, customer, ship-to, branch, salesperson, item, quantity, price, cost, disposition and any cancellation reason.
- Order and line notes, including internal notes that explain substitutions, backorders, expedites and price exceptions.
- Invoices, credit memos and returns, each carrying the original order number.
- Purchase orders and receipts linked to special-order and drop-ship lines.
- Customer, ship-to, item, supplier and contract pricing masters as they stood on export day.
- Attachments and document links, such as scanned packing slips, signed delivery receipts and customer purchase orders.
- Custom fields, user-defined tables and the queries behind reports people rely on.
- A data dictionary describing each table, field and code, plus the export queries used.
Where order history slips through during an upgrade#
Order history slips through at the edges of the database: notes, attachments, customizations and earlier purges. These are the parts an upgrade project tests least, because the upgraded system runs fine without them.
| Weak spot | What goes wrong | How to check |
|---|---|---|
| Order and line notes | Notes export separately or are cut short in standard reports | Open sample orders in the archive and compare notes word for word |
| Attachments | Files sit on a share whose path breaks when the old server is retired | Confirm the files themselves were copied, not just their paths |
| Custom tables | Tables added by past partners fall outside the export scope | List every non-standard table and decide keep or drop |
| Earlier purges | Older history was already removed years ago | Check old backups before assuming the archive is complete |
| Saved reports and views | Logic that explains margins or rebates is lost | Export report definitions and note what each one calculates |
How to verify the archive before anything is deleted#
Verifying a Prophet 21 archive means proving that the export holds every record in the date range you plan to purge, and that people can read those records without the application. Verification is cheap compared with discovering a gap after the purge.
Ask operations and finance to sign off separately. Operations confirms nothing in daily use is being removed; finance confirms the archive reconciles. Keep both sign-offs with the export log so an auditor, an acquirer or a future team can see exactly what left the live system.
- Match record counts by table and by year between the live database and the archive.
- Trace sample orders end to end: header, lines, notes, invoice, return and any linked purchase order.
- Reconcile yearly sales totals in the archive with the figures finance reported.
- Open attachments from a machine that has never had Prophet 21 installed.
- Record who verified, the date range covered and where the archive is stored.
Illustrative: a fastener distributor trims its database before an upgrade#
Illustrative: a fictional industrial fastener and MRO distributor with several branches runs Prophet 21 on its own servers and plans a version upgrade. Its partner proposes purging every closed order before a fixed cutoff to shorten conversion testing.
The VP of operations asks purchasing and sales what they still use. Purchasing relies on old special-order lines to source obsolete parts for long-standing customers. Sales reads price-exception notes when renewing contracts. Finance needs returns history for a rebate dispute that is still open.
The team exports closed orders, lines, notes, invoices, returns, masters and attachments to company-controlled storage, verifies counts and sample orders, and holds back the orders tied to the open dispute. Only then does the purge run. The upgrade proceeds on a smaller database, and the full history stays readable in plain files with a data dictionary.
What old order history is worth after the purge#
Old order history with notes, substitutions and exceptions shows how a distributor actually serves customers, which is the kind of operational record some AI developers license. Clean invoice totals alone say little; orders linked to the decisions around them say much more.
SourceX reviews archives like this with the SourceX Enterprise Data Value Framework, which weighs drivers such as domain expertise, human-generated signal, scale, recency, data cleanliness and rights against preparation cost and privacy burden. The first fit check uses metadata only, such as systems, years covered and record families, so no files change hands at that stage.
If a package proceeds, the SourceX five-step transaction runs Supply, Rights, Preparation, Approval and Delivery. Customer names and contact details are removed during preparation, customer contracts are checked for confidentiality limits, and the distributor keeps ownership because the records are licensed rather than sold. Large archives stay in the company's own storage or ship on encrypted drives.
Frequently asked questions
Does a Prophet 21 upgrade require a purge?
Not usually. A purge is a choice to reduce database size and speed up conversion, not a step every upgrade demands. Ask your Epicor partner whether your target version or hosting model raises size or performance concerns, then set any cutoff with operations and finance rather than accepting a default date.
How much order history should stay live after the upgrade?
Keep live whatever people look up in daily work: open returns, warranty and rebate claims, contract renewals and repeat orders for slow-moving items. Older closed orders can move to a verified archive. The right window depends on your customers, product life cycles and any retention obligations your accountant or counsel identifies.
Is a database backup enough as an archive?
A backup is worth keeping, but it is a weak archive on its own. Reading it means restoring a database to a compatible server, often alongside a matching application version, and that gets harder every year. Export key record families to open formats as well so anyone can read them.
What file formats work best for an order archive?
Formats that open without special software: delimited text or Parquet for tables, PDF for printed documents and original files for attachments. Keep the original order, invoice, customer and item numbers in every file, and ship a data dictionary that explains fields, codes and how the tables join.
Can we purge in stages instead of all at once?
Yes, and staging often reduces risk. Archive and purge the oldest years first, confirm reports and lookups still work, then move the cutoff forward. Each stage gets its own export log, record counts and sign-off, which makes the history of what left the system easy to follow.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.