Who Maintains Custom Integrations After Launch?

A custom integration can work perfectly on launch day and still become a business risk six months later. The question is not just who built it. It is who maintains custom integrations when an API changes, a new field gets added to Odoo, an order stops syncing, or the person who understood the workflow leaves.

If the answer is “the developer, probably,” you do not have an operating model. You have a future incident waiting for a bad Friday afternoon.

Who should maintain custom integrations?

The short answer: the party accountable for keeping the connected business process working should own integration maintenance. In practice, that is usually an internal IT or operations owner working with a technical team that understands the code, the systems on both ends, and the business rules in the middle.

That technical team might be an internal engineering department, a retained software operations partner, or the original development firm. The right choice depends on what the integration does and how much operational risk it carries. A nightly sync for a low-volume reporting export has different maintenance needs than an integration that moves customer orders, inventory levels, invoices, matter data, or manufacturing status.

What should not happen is splitting responsibility so finely that nobody can fix the whole process. One vendor says the website is fine. Another says Odoo received the request. The payment provider says it returned a response. Meanwhile, someone in operations is manually reconciling orders. That is not a technical dispute. It is an ownership failure.

The platform vendor does not maintain your business logic

Software platforms maintain their platforms. They may publish API documentation, retire old endpoints, adjust authentication requirements, and investigate outages within their own products. They generally do not maintain the custom code that connects their platform to yours.

For example, an e-commerce platform may keep its API available, and Odoo may keep running normally, while your custom order sync fails because a product mapping assumed every item had one SKU. That assumption belongs to the integration. So does the responsibility to update it when the business starts selling bundles, subscriptions, kits, or made-to-order products.

This distinction gets missed because an integration can look invisible when it is healthy. It is still software. Software needs an owner.

Maintenance is more than fixing broken connections

A team that maintains integrations is responsible for more than reacting when data stops moving. The real work is keeping the integration understandable, observable, and safe to change.

That starts with monitoring the actual business outcome, not merely whether a server returned a successful response. A request can complete with a 200 status code and still create a duplicate customer, skip an invoice, or push an invalid address into a shipping workflow. Technical health matters, but operational correctness matters more.

Maintenance also includes reviewing logs, handling failed jobs, updating credentials before they expire, and tracking platform changes. It means testing changes in a non-production environment when one exists, then deploying carefully instead of editing production code because an executive needs a new field by lunch.

There is also a quieter category of work: documentation. Someone needs to know what triggers the integration, which system is the source of truth, how conflicts are resolved, what data is intentionally excluded, and who can approve a change. Without that record, every future fix begins as archaeology.

The ownership model that holds up under pressure

For most businesses, the cleanest arrangement has three named roles. They do not need to be three different people, but the roles need to exist.

The business owner defines the process and decides what “correct” looks like. This is often an operations leader, finance lead, e-commerce manager, or department head. They answer questions such as whether an order can ship before an invoice is posted or which system wins when a customer record conflicts.

The technical maintainer operates and changes the integration. They troubleshoot errors, manage code and infrastructure, test updates, maintain credentials, and document what they change. They should have access to the relevant environments and enough context to trace a problem across systems.

The executive sponsor handles priority when maintenance competes with other work. This role matters because integration problems often reveal process decisions that no developer can make alone. If sales wants one workflow and accounting needs another, the integration cannot responsibly guess.

When these roles are unnamed, the task tends to land on whoever is most available. That person becomes the human middleware between departments. It works right up until it does not.

When the original builder should maintain it

Keeping the original builder involved is often sensible, especially when the integration includes custom business rules, legacy systems, or a workflow nobody wants to rediscover. They know why the code exists, not just what it does.

But familiarity alone is not enough. The arrangement is weak if the builder controls every credential, keeps the source code in a private account, has no current documentation, or treats routine maintenance as a favor. A business should be able to see its own code, access its own systems, and understand how support is requested and prioritized.

The original builder is a good long-term maintainer when they operate the work like production software: controlled changes, backups where applicable, clear release notes, monitoring, and a record of open risks. If they disappear after launch or only respond when something catches fire, they built a project, not an operation.

When to move integration maintenance to a new team

A handoff is reasonable when the existing provider is unresponsive, lacks the needed system knowledge, cannot explain the architecture, or has become a bottleneck for ordinary changes. It is also reasonable when one provider maintains the website, another maintains Odoo, and neither owns the connection between them.

Do not wait for a total failure to make that move. A transition is easier while the integration still runs and people can compare expected behavior with actual behavior.

Before a new team takes responsibility, they need more than login credentials. They need the source code and deployment process, system access, API keys or a documented rotation path, current field mappings, error logs, job schedules, and a list of known exceptions. They also need a real conversation with the people who use the workflow. Code can reveal logic. It rarely reveals why accounting has been correcting one edge case every month since 2022.

A responsible incoming team should not promise a quick rewrite on sight. First, they should map the flow, identify single points of failure, and determine whether the current integration needs stabilization, targeted repair, or replacement. Rebuilding can be the right call, but “we should start over” is often what people say before they understand the system.

What ongoing maintenance should include

The exact scope varies, but a maintained integration should have a few non-negotiables. There should be a documented owner for each connected system, a way to detect failed or stalled jobs, and a defined process for resolving bad data. Credentials and access should be managed so a departed employee does not take the keys with them.

Changes need a path too. A new product type, intake form field, approval step, tax rule, or customer status can alter the integration’s assumptions. Operations should know when a business change requires technical review, and the technical team should ask before treating a new field as a harmless request.

For higher-risk workflows, regular reviews are worth the effort. Look at recurring errors, manual workarounds, platform deprecations, growing data volumes, and undocumented exceptions. The goal is not to turn every integration into a major software program. It is to prevent a small, ignored weakness from becoming the reason orders, invoices, records, or stakeholder communications went missing.

The red flags to address now

You likely have a maintenance problem if nobody can say where the code lives, who owns the credentials, or how to tell whether the sync ran last night. The same is true if people routinely export CSV files to “make sure everything matches,” or if a change to one system causes quiet damage somewhere else.

Another red flag is a workflow that only one employee understands. That person may be excellent, but they should not be the permanent monitoring system for revenue-critical data. If their vacation plan can interrupt order processing, the process is not under control.

Parameter treats integrations as operating software, not a launch deliverable with a polite goodbye. That means starting with the business workflow, documenting the moving parts, and keeping one accountable technical team close enough to catch trouble before it becomes a cross-vendor blame session.

The useful question is not, “Who can fix this when it breaks?” Ask, “Who is accountable for this process still working after the next update, staffing change, and unusual order?” Name that owner now. Future you will have one less emergency meeting to attend.