Manufacturing
Should you migrate ERP history or archive it?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Most manufacturers should migrate open transactions, balances and active master data into the new ERP, then move closed history into a read-only archive that people can still search. The rule: migrate what the new system must act on, archive what people only look up, and review the archive for licensing before the old system is switched off.
Key takeaways
- Convert open orders, open jobs, inventory, active bills of materials and balances; leave closed history out of the new ERP.
- Full history conversion rarely pays back, because old part numbers, costing methods and custom fields must be remapped and reconciled.
- A read-only archive keeps traceability, audit and warranty lookups working after the legacy license ends.
- The archive export is the cheapest moment to inventory long transaction history for a possible data license.
- Schema notes and field descriptions disappear with the people who ran the old system, so write them down before cutover.
What are the real options when you replace an ERP?#
ERP history has four realistic destinations: full conversion into the new system, a partial conversion of open items with or without recent detail or summary totals, a read-only archive, or the old ERP kept alive in read-only mode. Most projects mix them, with different answers for financial balances, open transactions and closed history.
One more step belongs alongside any of these choices: assessing the archive for licensing before the legacy system is retired. Closed quotes, orders, jobs and quality decisions are being extracted anyway, so a metadata review of that history adds little effort and keeps an option open that disappears with the old server.
| Option | What moves | Where it works | Watch for |
|---|---|---|---|
| Full history conversion | Every closed and open transaction | Same-vendor upgrade with a stable data model | Remapping retired parts, costing changes and custom fields |
| Open items plus balances | Open orders, jobs, inventory, receivables, payables and ledger balances | Most cross-vendor moves | Users lose drill-down into old detail inside the new ERP |
| Open items plus recent detail | Open items and a limited window of closed transactions | Teams that compare current and prior performance in the new ERP | Choosing the window and reconciling it |
| Open items plus summary history | Open items, plus monthly or yearly totals by part, customer and job in custom fields or tables | Teams that want trend reports in the new ERP without old detail | Custom tables to maintain through upgrades, and totals nobody can drill into |
| Read-only archive | Closed history exported to a searchable store | Traceability, audit and warranty lookups | Losing schema knowledge and attachments |
| Legacy ERP kept read-only | Nothing; the old system stays up | A short overlap after go-live | Ongoing license, server and security patching cost |
| Archive, then a licensing review | Closed history exported once, then assessed on metadata only | Long quote, job and quality histories with recorded outcomes | Customer drawings, export-controlled orders and personal details mixed into the export |
What belongs in the new ERP?#
The new ERP should receive only the records it must act on after go-live: open transactions, current balances and active master data. Anything that will be shipped, received, built, invoiced or paid in the new system needs to be there on day one.
Master data deserves the hardest look. Converting every inactive part, obsolete customer and retired routing carries old mistakes forward, so many teams clean and convert only active records and leave the rest in the archive.
- Open sales orders, purchase orders and work orders or jobs, with their current status
- On-hand inventory by location, with lot and serial numbers where traceability depends on them
- Active parts, bills of materials, routings and approved supplier lists
- Customer and vendor masters with current terms, contacts and tax settings
- Open receivables and payables, plus general ledger balances by period for comparisons
- Open quality items, such as unresolved nonconformances and corrective actions
Why full history conversion is usually a poor trade#
Full history conversion is usually a poor trade because closed transactions must be remapped to a data model they were never built for. Part numbers change, units of measure get retired, costing methods move between standard and actual, and old custom fields have no clean home in the new system.
Every converted period also has to be reconciled, or finance cannot trust the reports built on it. That work competes with testing, training and cutover rehearsal, which are the activities that decide whether go-live succeeds.
The exception is a same-vendor upgrade where the data model barely changes. Even then, teams often convert a recent window of closed history and archive the rest, because converted history that nobody queries still has to be tested.
What a usable ERP archive needs to keep#
A usable ERP archive keeps closed history in a form that people can still search by order, job, lot, serial number, customer and part. A database backup that only one retired administrator can restore is not an archive; it is a liability.
Common archive formats include a read-only copy of the old database on a supported server, exported tables in an open file format with a data dictionary, or a commercial archiving product with a search screen. Whichever you choose, keep the links between records, not only the records themselves.
Retention obligations come from tax rules, customer quality agreements and product liability exposure. For US federal tax, IRS Revenue Procedure 98-25 treats records kept in a computerized accounting system as records to retain while their contents may be material to tax administration, at a minimum until the limitation period for each tax year expires, which is one reason the archive must stay usable rather than merely stored. Finance, quality and counsel should agree a retention period for each record family before the archive is built, and confirm tax periods with your tax advisor.
The last column of the table is a first read on which record families are worth a licensing look; a metadata fit check confirms it.
| Record family | Typical lookup after go-live | Keep in the archive with | Licensing interest |
|---|---|---|---|
| Closed sales orders, shipments and invoices | Customer disputes, repeat orders, tax questions | Customer, part and ship-to references | Modest alone; customer names and prices removed |
| Closed jobs, labor and material issues | Cost history and requoting | Routing, operation and work center references | Strong when estimated and actual hours both survive |
| Lot and serial genealogy | Traceability requests and field problems | Supplier lots, receipts and inspection results | Useful when linked to inspection and field results |
| Nonconformances, corrective actions and returns | Audits, customer complaints, warranty claims | Disposition, root cause and linked jobs | Strong when dispositions and root causes are recorded |
| Quotes and estimates | Pricing new work against old work | Quote lines, cost buildups and won or lost status | Strong when won or lost status and cost buildups survive |
| Engineering revisions and attachments | Building to the right revision | Revision history, with customer drawings flagged | Own-product changes may qualify; customer drawings excluded |
Why the archive deserves a licensing review before shutdown#
An ERP archive deserves a licensing review because long, linked transaction histories are the kind of operational record AI developers license to train and test systems that quote, schedule, plan and resolve exceptions. Quotes with won or lost outcomes, jobs with estimated and actual hours, and nonconformances with dispositions show how real manufacturing decisions were made.
Timing matters. Once the legacy license lapses and the server is wiped, the export tools, the schema knowledge and the people who understood the custom fields are gone. Reviewing the archive while the old system still runs costs far less than reconstructing it later.
A licensing review does not mean the archive is shared. The first pass uses metadata only: systems, years covered, record families and known restrictions. Customer-owned drawings, export-controlled work and personal details are marked for exclusion or removal, and data is licensed, not sold, so the company keeps ownership.
Document the archive the way a dataset is documented. The Data & Trust Alliance's Data Provenance Standards group dataset metadata into source, provenance and use, which maps well to what an archive needs: where records came from, how they were extracted and who may use them for what.
Illustrative: a truck body builder retiring a legacy on-prem ERP#
Illustrative: a fictional builder of custom truck bodies and service trailers is moving from an aging on-premises ERP to a cloud ERP from a different vendor. The project team converts open orders, open jobs, inventory with serial numbers, active bills of materials and period balances, and nothing older.
Closed history goes into a read-only database copy with a written data dictionary that explains the custom option codes the sales team used to configure each body. Quality can still trace a chassis serial to its build record, and finance can still pull old invoices. Before the old server is decommissioned, the CFO asks for a metadata fit check on the quote, job and warranty history.
The fit check flags fleet customers' upfit specifications attached to quote lines, and a small set of orders built to a municipal customer's drawings, for exclusion. The remaining quote outcomes, job cost history and warranty dispositions move into a licensing review, and the archive serves both purposes without a second extraction.
Questions to settle before cutover#
The CFO and IT director should settle archive ownership, access and retention before cutover, not after the legacy server is scheduled for shutdown. These decisions are cheap while the old system is still running and expensive once it is gone.
- Who owns the archive after go-live: finance, IT or quality?
- Which retention period applies to each record family, and who signed off on it?
- Who can query the archive, and how is access logged?
- Is the data dictionary written down, including custom fields and status codes?
- Are attachments exported with their links to orders, jobs and parts?
- Are any records under a legal hold that blocks deletion?
- Has the archive had a metadata-only licensing fit check before the old license ends?
How SourceX looks at a retiring ERP archive#
SourceX treats a retiring ERP archive as candidate supply for the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check starts from a description of the archive, covering systems, years, record families and known restrictions, and nothing is shared during the initial assessment.
Record families are weighed with the SourceX Enterprise Data Value Framework to decide which are worth taking further. Large archives stay in the company's own storage or ship on encrypted drives. If a package proceeds, its SourceX Evidence Packet records where the records came from, how they were extracted, what was excluded and who approved the release.
Frequently asked questions
Can we keep the old ERP running in read-only mode instead of archiving?
Yes, for a period. Keeping the legacy ERP up after go-live gives users familiar screens for lookups, but it carries license, server, backup and security patching costs, and the people who know the system drift away. Many teams plan a short overlap and then move closed history into a supported archive.
Does archived history still count for audits and traceability?
It can, if the archive keeps records complete, unaltered and searchable, with links between orders, lots, inspections and shipments. Auditors and customers generally care that you can produce the record and show it was not changed. Check customer quality agreements and your own retention policy for any format requirements.
What happens to custom fields and user-defined tables?
Custom fields often hold the most specific information in an old ERP, such as reason codes, inspection notes or customer requirements. They rarely map cleanly into a new system, so archive them with plain descriptions of what each field meant and when it was used. Without that description, the values lose most of their meaning.
Does licensing archived data mean we give up ownership?
No. A data license grants defined use rights for a defined scope and term while the company keeps ownership. The license states what the buyer may do with the records, what is excluded and what happens at the end of the term. The archive itself stays with you.
Should attachments go into the archive?
Usually, but sort them by type. Packing slips, certificates and inspection reports are often needed for lookups. Customer drawings and specifications should be flagged in the archive, because they are commonly governed by customer confidentiality terms and are usually excluded from any data license.
Sources
- The Data & Trust Alliance's Data Provenance Standards (version 1.0.0 specification) define dataset metadata in three groups: Source, Provenance and Use. Source
- Rev. Proc. 98-25 treats machine-sensible records in a taxpayer's automatic data processing system as records under IRC 6001 that must be retained so long as their contents may become material to tax administration, at a minimum until the period of limitation for assessment, including extensions, expires for each tax year. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.