ERP Renewal: Inventory Every Integration Before You Accept the Upgrade Plan
The ERP renewal proposal usually prices the ERP.
Your actual risk sits around it.
A customer order enters through one system. Inventory updates somewhere else. A scheduled file moves to a bank. A service account pushes data into payroll. A custom report feeds a lender, regulator, distributor, or executive team. Then somebody says the upgrade is straightforward because the core platform is supported.
Okay, cool. Which of those connections has been tested on the new version?
Before you accept an ERP renewal or upgrade plan, build an integration inventory that finance, operations, IT, security, and the implementation partner can all challenge. Price the work around the platform. Test the business transactions that cross its boundary. If the vendor cannot help you do that, the proposal is not ready.
The ERP is bigger than the software named on the invoice
An ERP can be the center of a messy operating system that nobody sees in one place.
The architecture diagram may show clean lines between finance, inventory, payroll, CRM, banking, ecommerce, tax, warehouse, and reporting systems. The working environment may also contain nightly CSV files, scripts written by a former employee, shared folders, manual corrections, custom database queries, middleware mappings, and credentials owned by a consultant.
Those connections can survive for years because they keep moving data. Survival is not the same as support.
A renewal meeting focused on modules, users, hosting, and the subscription term can miss the work most likely to delay an upgrade. The vendor may own the application release while your team owns the interface, the third party owns the connector, and a business analyst owns the only useful test. If nobody writes down those boundaries, every party can be correct about its own scope while the upgrade still fails.
NIST’s configuration management guidance gives buyers a useful discipline here. It treats applications and middleware as system components, calls for a component inventory, and says upgrades and modifications should move through proposal, justification, testing, review, and disposition. NIST wrote that guidance for security-focused configuration management, not ERP procurement. The control logic still applies: you cannot evaluate the impact of a change when you do not know which components and connections exist.
Build one integration register before you discuss the term
Do not ask each department for a list and leave the answers in separate spreadsheets. Create one register with a row for every material connection.
| Field | What to record |
|---|---|
| Business transaction | The real event, such as order to cash, payroll, payment, receipt, shipment, or close |
| Source and destination | Both systems, tenants, environments, and legal entities involved |
| Method | API, middleware, database query, managed connector, file transfer, email, manual import, or custom code |
| Direction and schedule | Inbound, outbound, two-way, event-driven, daily, weekly, or period-end |
| Data and sensitivity | Main objects, financial importance, personal data, credentials, and regulated records |
| Owner | Business owner, technical owner, vendor owner, and support route |
| Authentication | Service account, certificate, key, token, SSO identity, and renewal date |
| Support state | Supported, custom, deprecated, unknown, or dependent on another contract |
| Failure evidence | Monitoring, reconciliation, alert, ticket path, and last known incident |
| Upgrade test | Test case, environment, expected result, tester, date, and evidence |
| Exit dependency | Export, replacement work, retained history, documentation, and transition rights |
| Full cost | License, middleware, partner support, internal labor, testing, and remediation |
Start with system and middleware exports, job schedulers, API gateways, identity records, file-transfer tools, integration-platform consoles, service accounts, database jobs, and support tickets. Then sit down with the people who close the books, release orders, ship product, run payroll, reconcile cash, and fix exceptions.
You need both views. Technical records reveal connections. Business users reveal which ones matter.
Find the integrations that hide in normal work
The obvious API is rarely the whole story.
Look for recurring files with names such as final, upload, bank, payroll, inventory, tax, commission, or month-end. Review scheduled jobs that run under personal or generic accounts. Check where users download data, clean it in a spreadsheet, and upload it somewhere else. Inspect reports that another team treats as an input instead of an output.
Support history is especially useful. Old tickets can expose recurring mapping errors, certificate expirations, timing problems, rejected files, duplicate transactions, and manual workarounds that never reached the architecture record.
Ask every owner a blunt question: If this connection stopped on the first business day after the upgrade, how would we know, and who would fix it?
“The vendor handles it” is not an owner. Get the company, team, named route, response commitment, and contract that covers the work.
Make the upgrade proposal price the dependency work
An upgrade estimate can look reasonable because it excludes the hard parts.
Put the integration register next to the proposal and mark who is responsible for each activity:
- Discovery and documentation
- Compatibility review
- Code, mapping, connector, or certificate changes
- Test-data preparation
- Environment refresh and access
- Unit, integration, security, and business acceptance testing
- Defect correction and retesting
- Cutover, reconciliation, rollback, and post-launch support
Then compare that list with the statement of work. If an activity is missing, it has not become free. It has become unclear.
This is where a measurable technology implementation SOW matters. Every material integration should have a delivery owner, acceptance evidence, exception process, and commercial treatment. If a connector is out of scope, state who will handle it and what must be finished before cutover.
Include the cost of parallel systems, temporary middleware, consultant support, test environments, internal business time, and a bridge term if the organization cannot finish safely before the renewal deadline. The subscription price is only one line in the decision.
Test transactions, not connection lights
A green connector status proves that something connected. It does not prove that the business transaction completed correctly.
Test through the business process. Create or select controlled records, follow them across each system, and reconcile the result. Check amounts, dates, customer and supplier identity, tax treatment, units, status changes, approvals, exceptions, and downstream reporting. Use test data and approved procedures. Do not create a production financial mess to make the test feel realistic.
Microsoft’s current Dynamics 365 Finance and Operations update guidance shows why buyers should settle this before the update window. Microsoft says its automatic update process updates the user acceptance testing sandbox seven days before production. The same guidance says customers can pause only one consecutive service update under the current cadence. That is specific to Microsoft’s service model, but the buyer lesson is broader: a vendor’s update calendar does not expand because your integration list is unfinished.
Seven days may be enough to rerun prepared tests. It is not much time to discover who owns a custom bank file, find a missing certificate, negotiate partner scope, create test data, and get finance to validate the result.
Build reusable tests before the renewal. For each critical transaction, keep the input, expected output, evidence location, tester, last result, known exception, and rollback action. Automation helps on repeatable flows, but somebody still has to judge whether the business result is correct.
Put every integration into a decision bucket
Do not finish with one recommendation for the whole ERP. Give each integration a treatment.
Keep it when the connection is needed, supported, owned, tested, and reasonably priced.
Correct it when the business need remains but documentation, authentication, monitoring, mapping, or support is weak.
Replace it when a supported API or connector removes custom work without creating a worse commercial dependency. Make the replacement earn its place through the same test.
Retire it when the consuming process is gone, the output is unused, or a manual workaround has quietly become permanent. Confirm records, access, and downstream jobs before removal.
Bridge the current term when the core platform still fits but the organization needs time to remediate dependencies or run a credible comparison.
Compare another platform or operating model when integration cost, support gaps, forced update timing, or exit restrictions make the current path hard to defend.
If replacement is on the table, run the SaaS data export test before treating migration as a slide in a presentation. Data access is not the same as usable history, configuration, attachments, audit records, and integration logic.
Ask these questions before you sign
Send the vendor and implementation partner the register, then require written answers:
- Which integrations have they reviewed against the target release?
- Which interfaces, APIs, connectors, or methods are deprecated or unsupported?
- What work is included, excluded, assumed, or dependent on another party?
- Who owns test planning, test data, defect correction, and acceptance?
- How much time will the test environment receive before production changes?
- What happens if a critical transaction fails acceptance?
- What rollback options exist, and what data must be reconciled afterward?
- Which credentials, certificates, allowlists, endpoints, or network paths will change?
- What support applies to custom code and third-party integrations after launch?
- What does the customer receive at termination, and what assistance is available to move it?
- Which fees sit outside the renewal and upgrade estimate?
- Can the term or notice date accommodate unfinished remediation without forcing a bad launch?
Start this work before the notice deadline. A good IT contract renewal calendar creates enough room to inventory, test, negotiate, bridge, or compare without turning time pressure into vendor leverage.
The decision is not simply whether the ERP works today. You are deciding whether the full operating system around it can survive the proposed term and upgrade path.
Get every connection on one page. Put an owner and test beside it. Price the work the proposal left out. Then decide whether to renew, remediate, bridge, or compare.
If your ERP agreement or upgrade proposal is approaching a deadline, request a Contract and Spend Risk Review. Bring the agreement, proposal, invoices, architecture records, integration exports, service accounts, support history, test evidence, and notice dates. Catch Advisors will help you reconcile the commercial plan with the systems and people that have to make it work.