The Vendor Lock-In Question Behind Integrations

The uncomfortable moment usually comes after go-live. A sales field changes in Salesforce. Finance adjusts a product rule in the ERP. A customer record stops syncing. Someone asks a simple question: who can change the integration?

If the answer is only the original vendor, the company has learned something important. It did not buy a working connection between systems. It bought a dependency.

That dependency is not always visible during procurement. The demo works. The proposal is clear. The price is approved. But the operational control question is often left until later, when the system is already carrying orders, approvals, prices, or customer data.

Lock-in is not only a contract problem

When leaders hear vendor lock-in, they often think about licensing terms or cancellation clauses. Those matter. But in integration work, lock-in is usually more practical.

It shows up in small, operational questions:

• Can your team see the mapping between Salesforce and the ERP?
• Can someone explain which system owns each field?
• Can changes be tested without touching production data?
• Can another engineer maintain the work without reverse engineering it first?
• Do you have the credentials, documentation, and source code needed to operate it?

If the answer to those questions is unclear, the risk is not theoretical. Every later change becomes slower. Every incident depends on the vendor queue. Every internal discussion starts with the same sentence: we need to ask them.

The warning sign: the integration is a black box

A black box integration can be attractive because it removes complexity from the buyer. You describe what should happen. The vendor configures it. The business sees records move from one system to another.

That can be enough for a simple use case. But most B2B operations do not stay simple. Price logic changes. Customer hierarchies change. Approval rules change. New warehouses, currencies, legal entities, or sales channels appear. The integration has to change with the business.

When the integration is a black box, change becomes a request instead of a capability. The company cannot inspect the rule. It cannot compare the current behaviour with the intended behaviour. It cannot decide whether a change is small, risky, or urgent without outside help.

The issue is not that vendors are bad. Many do good work. The issue is that the buyer has no operational handle on work that has become part of the business.

What ownership should mean

Ownership is more than having an admin login. It means the business can understand, maintain, and replace the integration if needed.

For a Salesforce to ERP connection, that usually means five concrete things.

1. A documented data ownership model

For each important object and field, the company should know which system is the source of truth. Customer address. Product price. Credit status. Order status. Opportunity stage. If two systems can overwrite each other, the integration will eventually create conflict.

2. Visible mapping and transformation rules

Mapping should not live only inside a consultant's head or an inaccessible platform screen. A future engineer should be able to see how fields move, which values are transformed, and which records are excluded.

3. A safe test path

Changes need a place to fail safely. That can be a sandbox, a test tenant, sample data, or a controlled staging flow. The specific tool matters less than the habit: never discover integration behaviour for the first time in production.

4. Clear credentials and access ownership

Service accounts, API keys, certificates, and connected apps must belong to the company, not to an individual vendor account. Access should be revocable and auditable. Nobody should need a former consultant to retrieve the key that keeps orders moving.

5. Handover that another engineer can use

A handover document should explain what runs, where it runs, how errors appear, how to deploy changes, and what to check when something fails. This is not bureaucracy. It is operational insurance.

Questions to ask before you sign

The best time to reduce lock-in is before the project starts. These questions are simple enough for a leadership meeting and specific enough to expose real risk.

1. What exactly will we own at the end? Ask for code, configuration exports, diagrams, field mappings, credentials, and deployment notes.
2. What will only the vendor be able to change? This question matters because some platforms are intentionally closed. That may be acceptable, but it should be a conscious decision.
3. How will we test an ERP or Salesforce change before it affects live orders? A vague answer here usually means incidents will be found by users.
4. How does another engineer take over the work? If the answer is another paid onboarding project, you are buying a dependency.
5. How are failures surfaced to the business? Silent failure is where lock-in becomes operational pain. The business needs visibility, not only the vendor.

The trade-off is not vendor or no vendor

This is not an argument against vendors or integration platforms. Many companies need both. The trade-off is whether the vendor remains a useful partner or becomes the only party that can keep the business moving.

A good integration partner should be comfortable leaving the company in control. That does not mean every internal team must be able to rewrite the code. It means the company can inspect the work, understand the risk, and bring in another qualified person without starting from zero.

For Swiss and DACH B2B companies, that control matters because operations tend to depend on long-lived systems. ERPs stay. Customer data stays. Order processes stay. The integration layer should be built with the same long-term discipline.

Before the next project, do not only ask whether the integration can be delivered. Ask whether you will still control it after it is delivered.