Private equity and portfolios
ERP consolidation after acquisitions: what to do with the old system's data
By SourceX Editorial · Updated
Short answer
During ERP consolidation after an acquisition, sort the old system's data three ways: migrate open transactions and active master data, archive closed history in a read-only store, and preserve linked history such as quotes, nonconformance reports and order exceptions with their relationships intact. Do not switch off the old instance until that linked history is exported and verified.
Key takeaways
- Migrate what the business needs to operate tomorrow, archive what auditors and disputes need, and preserve what explains how work was done.
- Linked history, such as a quote that became an order, a shipment and a credit memo, is the data most consolidations lose.
- Custom tables, user-defined fields, reason codes and attachments rarely map to the new ERP and need their own export.
- Keep the old instance or a verified, restorable copy until legal, finance and operations have signed off on the archive.
What should be migrated, archived or preserved?#
The old ERP's data falls into three treatments: migrate what is open or active, archive what is closed and needed for reference, and preserve the linked operating history that explains decisions. Mixing these up is how consolidations either overload the new system or discard the most useful records.
| Data | Examples | Treatment |
|---|---|---|
| Open transactions | Open sales orders, purchase orders, open AR and AP, work in progress | Migrate |
| Active master data | Customers, items, vendors, bills of materials, price lists, routings | Clean, then migrate |
| Closed financial detail | Posted journal lines, closed invoices, prior-year subledgers | Migrate balances, archive detail |
| Linked operating history | Quote to order to shipment to return chains, credit memos with reason codes | Preserve with links intact |
| Quality and service records | Nonconformance reports, CAPAs, RMAs, warranty claims, service orders | Preserve with links intact |
| Notes and attachments | Order notes, customer correspondence, drawings, inspection photos | Preserve with parent record IDs |
| Audit and change logs | User activity, price overrides, approval history | Archive for compliance and disputes |
Why linked history is what most consolidations lose#
Linked history is lost because migration projects are scoped to the target system's data model, and the old system's relationships, notes and custom fields do not fit that model. A field mapping moves customer numbers and open balances cleanly; it does not move the comment a buyer left on a rejected lot or the reason code on a credit memo.
Integrators also scope tightly to control effort. Converting closed transactions is slow and error-prone, so statements of work often say open items only, and the rest is left on the old instance with a plan to switch it off later. Later tends to arrive with the hosting renewal, after the people who knew the old system have moved on.
The loss matters for more than reference. Linked history settles warranty disputes, supports pricing analysis for the combined business, and shows how the acquired team handled exceptions. It is also the kind of record AI developers value, because it connects a request to a decision and an outcome.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Decommission checklist for the old instance#
The old instance should be switched off only after a written checklist is complete and signed by IT, finance and legal. Each item below is cheap while the system is running and difficult or impossible afterward.
Do not assume a built-in export is complete. Oracle's NetSuite help, for example, says the Full CSV Export does not currently export all data, and points to saved search exports, report exports, SOAP web services or SuiteAnalytics Connect for the rest. It also warns that opening a NetSuite CSV directly in Excel loses precision on numbers longer than 16 digits, which can silently break the record IDs that keep quotes, orders and returns joined. Import ID columns as text.
- Confirm with counsel whether any legal hold, audit or open dispute covers the old system's records.
- Inventory custom tables, user-defined fields, reports and integrations, including anything a reseller built.
- Take a full database backup and confirm someone can restore it outside the vendor's environment.
- Export application-level data with keys, so quotes, orders, shipments, returns and credit memos still join.
- Export attachments and notes with the ID of the parent record each belongs to.
- Capture the data dictionary and code lists: status codes, reason codes, units of measure and item classes.
- Reconcile record counts and totals between source and export for each table.
- Review the ERP vendor and hosting contracts for data return rights and any retrieval window after termination.
- Record who approved the shutdown and where the archive lives.
Archive formats compared#
The archive format decides whether anyone can use the history later without the old software. Choose by who will need the data: auditors, the commercial team, or a future rights and preparation review.
Many groups keep two copies: a full backup as insurance and flat exports with keys and a dictionary for everyday use. Flat exports are also the easiest format to inventory, because they can be described by table, date range and volume without opening a single record.
| Format | Strength | Weakness |
|---|---|---|
| Full database backup | Complete, including tables nobody remembers | Needs the right database engine and schema knowledge to read |
| Read-only old instance | Users see history in familiar screens | Ongoing license, hosting and security patching |
| Flat exports with a data dictionary | Readable by any tool, easy to scope and review | Links survive only if keys are exported deliberately |
| Third-party archive platform | Search and retention controls in one place | Another vendor, with export terms of its own |
Who decides what happens to the old system's data?#
The portfolio CIO or CTO runs the consolidation, but decisions about the old system's data belong to several owners. Finance decides what accounting history must stay retrievable, legal decides which holds and retention rules apply, and operations decides what history the business still uses day to day.
Ownership of the records also needs a check. If the acquired company still exists as a separate legal entity, its records may remain its property after systems merge, and any later license would be signed by that entity. If entities were merged, confirm which entity now holds the archive and the contracts that govern it.
Write the decisions into a one-page archive register: system, legal entity, what was migrated, what was archived, where each copy lives, who owns it, the retention rule and the approval date. The register is the first thing a future auditor, acquirer or rights reviewer will ask for.
Illustrative: three ERPs after two add-ons#
Illustrative: a fictional industrial distribution platform runs NetSuite and acquires two add-ons, one on Epicor and one on SAP Business One. The integration plan migrates open orders, inventory balances, customers and items into NetSuite and schedules both old systems for shutdown at their next renewal.
The portfolio CIO adds a preservation track. The Epicor company holds years of quotes linked to orders, shipments and returns, with credit memo reason codes and buyer notes, so these are exported with keys and a code list. The SAP Business One company kept little beyond invoices after an earlier migration, so only a database backup is retained.
Later, a rights review finds the Epicor company's exception history is company-owned and could be scoped for a license, while the other archive is kept for audit only. The preserved links are what made the first archive worth reviewing at all.
Where data licensing fits in the consolidation plan#
Data licensing fits as a reason to preserve linked history, not a reason to delay the consolidation. The new ERP goes live on schedule; the archive simply keeps enough structure to be assessed later.
Under the SourceX Enterprise Data Value Framework, the drivers that weigh most for an ERP archive are data cleanliness, recency, human-generated signal such as notes and reason codes, and rights, while preparation cost reduces net value. SourceX runs the work as the SourceX five-step transaction, starting with Supply from your exports; large archives stay in your own storage, and nothing is shared during the initial fit check.
Frequently asked questions
How long should the old ERP stay readable?
Long enough to cover the longest of your retention requirements, open audits, disputes and warranty periods, which counsel and finance should confirm. Many groups switch off the live instance once verified exports and a restorable backup exist, rather than paying to keep the old software running indefinitely.
Should we migrate all history into the new ERP instead?
Usually not. Loading years of closed transactions slows the project, adds conversion errors and clutters the new system with codes that no longer apply. Migrating balances and active records, then keeping detail in a well-documented archive, gives most teams the history they need with less risk.
Does archiving the old system satisfy privacy deletion obligations?
No. An archive still holds personal data, so retention schedules and deletion requests apply to it too. Record which deletion requests were honored in the old system before shutdown, and make sure the archive does not quietly keep data the company agreed to remove.
What if the reseller who customized the old ERP is gone?
Start with the database itself: table names, user-defined fields and stored reports usually reveal the customizations. Interview the longest-serving users about which screens and fields they relied on, and document code lists from live data before anyone loses access.
Can an archived ERP still be licensed after the companies merge?
It can, if the entity that now holds the records has the right to license them and customer and vendor terms allow it. The archive needs to keep provenance, meaning which company and system each record came from, so the rights review can trace it.
Sources
- Oracle's NetSuite help says the Full CSV Export (Setup > Import/Export > Export Tasks > Full CSV Export) does not currently export all data. It covers accounting lists, classes, contacts, customers, departments, employees, items, notes, partners, saved reports you own, tasks, the transaction detail report and vendors. Source
- Oracle's 'Extracting Data from NetSuite' page lists ways beyond the Full CSV Export: exporting saved search results to CSV, exporting report results, writing a SOAP web services program, or using SuiteAnalytics Connect. It notes that ODBC access is an additional service with a fee. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.