iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The company must name an ongoing owner for every ERP integration. That owner may be the original implementation partner under a continuing support agreement, internal IT or an ERP team, a replacement integration partner, or an application management services (AMS) provider. The fact that a partner built an integration does not, by itself, mean it is responsible for maintaining it after the project ends.
Check the support agreement and statement of work for who handles connector code, monitoring, credentials, incident recovery, and changes. The ERP publisher’s standard-product support should not be assumed to cover custom integrations. Microsoft’s Dynamics 365 guidance illustrates one platform-specific division of responsibility: Microsoft is responsible for its standard infrastructure and platform, while customers and implementation partners manage business processes and test changes before deployment. Microsoft’s servicing guidance is not a rule for every ERP product.
Why integration support needs an explicit owner
Implementation delivery and ongoing support are separate responsibilities. A project can be accepted and closed while its interfaces still need monitoring, troubleshooting, security maintenance, and updates as connected systems change. Unless an agreement assigns that work, the company may be left without a clear route to restore a failed data flow.
Integration support also spans technical and business decisions. Technical staff investigate the connection and operate its services; a business process owner confirms that the data, transaction, and rules reflect the intended outcome. Neither role can reliably replace the other.
#1 Best Overall
Microsoft’s Dynamics 365 documentation makes the shared-responsibility point explicitly: “However, servicing Dynamics 365 isn’t solely Microsoft’s responsibility.” That statement concerns Microsoft’s platform and should not be generalized into a universal ERP support policy. Other publishers may define their boundaries differently. Read the Dynamics 365 servicing guidance and check the applicable product and support terms.
Who can own the work after handover?
Support can be internal, external, or split between the two. The right fit depends on the organization’s skills and coverage, the complexity and customization of its integrations, planned upgrades, and what its contracts actually include.
Rank #2
Internal ERP or IT team
An internal team can own operations when it has the platform and integration skills, service coverage, access, and authority to make or coordinate changes. It still needs a defined route to the ERP publisher for issues covered by standard-product support.
Recommended Free Tools
Original implementation partner
The original partner may be well positioned because it knows the configuration, but past project work is not proof of continuing support. Confirm that an active agreement covers the specific integrations, response terms, exclusions, access, and maintenance tasks.
Replacement partner or AMS provider
A new partner or application management services provider can maintain custom integrations when the project partner exits or internal expertise is limited. Establish platform experience, onboarding and knowledge transfer, service hours, escalation, change control, and ownership of code and credentials before relying on the arrangement.
Hybrid support
A company can keep business decisions and first-line triage in-house while an external team handles complex ERP or integration work. Define where one team’s responsibility ends and the other’s begins, including who keeps ownership of an incident through restoration.
Vendor maintenance and AMS are not interchangeable terms. Standard-product maintenance may be distinct from support for customer customizations and integrations; verify the specific scope with the ERP publisher and service provider. ERP Research’s overview of ERP maintenance and support describes this distinction, but the contracts control the actual obligations.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Set a responsibility map before the partner exits
Assign both the work and the decision authority. A useful starting map is:
| Responsibility | Typical owner | What to define |
|---|---|---|
| Business process and data meaning | Process owner or data steward | Expected behavior, authoritative data, validation, and approval of business-rule changes. Microsoft implementation guidance addresses business-process ownership. |
| Integration technical operation | Internal IT, ERP team, or contracted partner | Monitoring, incident triage, credentials, security, performance, troubleshooting, restart and recovery, deployment, and testing. Microsoft implementation guidance covers operational considerations. |
| ERP standard product and service | ERP publisher under the applicable support agreement | Covered product defects, platform services, updates, and support channels. Microsoft’s servicing guidance provides a Dynamics 365 example. |
| Custom code, connectors, and partner solutions | Internal technical team or contracted partner | Maintenance scope, compatible updates, regression testing, release, and deployment responsibility. Microsoft’s servicing guidance discusses customer and partner responsibilities for Dynamics 365 changes. |
| Integration estate and architecture | Named architecture or ERP owner | Inventory, dependencies, ownership changes, and decisions to replace or retire connections. ERP Company’s integration-ownership overview discusses integration ownership. |
| User-facing support and escalation | Help desk or first-line team, then technical owner | Ticket intake, severity, required diagnostic information, response coverage, and escalation path. Microsoft implementation guidance addresses transition and support planning. |
Use the map to resolve ambiguous boundaries: standard ERP product issue, ERP configuration, custom code, middleware, connected service, infrastructure, authentication, or business data. The exact division depends on the company’s product and contracts.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Route an incident to the right owner
For a broken flow, first establish what failed and whether the transaction’s intended behavior is correct. A standard-product defect belongs in the applicable ERP publisher support channel. A custom connector or integration failure should go to its named technical owner, who can coordinate with the middleware or connected-system provider. A business process owner should validate disputed rules or data meaning.
- Open a ticket through the help desk or agreed intake channel. Include the affected integration, business impact, time observed, transaction or correlation identifiers if available, and any relevant error or alert.
- Classify the likely boundary. Separate user or process questions, ERP product defects, configuration, custom code, middleware, third-party service outages, infrastructure, authentication, and data quality.
- Assign the incident to the named technical owner. That owner coordinates across providers as needed and remains responsible for tracking the issue through recovery, as defined in the support arrangement.
- Bring in the process owner when meaning or rules are in question. The technical team can diagnose delivery; the business owner confirms whether the expected transaction and outcome are correct.
- Escalate through the contract’s route. Use the publisher channel for covered standard-product problems and the relevant partner or service provider for custom integration work.
This is an operational triage approach, not a guarantee of contractual responsibility; support obligations depend on the system and agreements in force. Microsoft’s servicing guidance describes its own support levels and escalation approach.
Free tools Windows power users keep installed
One-click scans. No signup required.
What a complete handover must include
Acceptance paperwork alone is not enough to operate an integration. Microsoft’s published go-live guidance calls for a support transition plan and for teams to have the resources, tools, access, and training to operate the solution. Its integration support guidance identifies data management at both ends, security, performance, monitoring or auditing, and troubleshooting as areas to scope. Microsoft implementation guidance and Microsoft integration guidance provide platform-specific examples.
- Integration inventory: endpoints, source and destination systems, environments, dependencies, owners, and business criticality.
- Behavior and data: field mappings, triggering events, expected outputs, business rules, and known exceptions.
- Access and security: service-account and credential ownership, renewal or expiry process, access controls, and security responsibilities.
- Operations visibility: monitoring dashboards, alerts, logs, incident history, and the person or queue receiving each alert.
- Recovery: retry, replay, rollback, reconciliation, and manual recovery instructions, including how to handle a partially completed transaction.
- Change capability: source-code or configuration access where applicable, deployment process, change history, and partner or third-party dependencies.
- Verification: test cases and a repeatable post-change check, including regression tests relevant to ERP or connected-system updates.
- Support arrangements: named technical and business owners, hours, severity definitions, escalation contacts, ticket process, and applicable contracts.
- Knowledge transfer: training and an overlap or transition period for the receiving team.
Treat this as an operational checklist, not a universal contractual standard. Adapt it to the architecture and have the receiving team verify that it can actually access the systems and perform the recovery steps.
Quick Recap
Questions to ask the current partner and next maintainer
- Which integrations and custom components are expressly in support scope, and what is excluded?
- Who receives and investigates alerts, and who owns the incident until the business flow is restored?
- Who controls service accounts, API credentials, renewals, and access when staff or providers change?
- Who approves business-rule changes, and who implements code or connector changes?
- What testing and deployment steps are required after ERP, middleware, or connected-system updates?
- Which support hours, severity levels, response commitments, and escalation routes apply?
- What documentation, code, configuration, logs, and test evidence will be delivered at handover?
- How will the receiving team learn to operate and recover the integrations?
