How to Connect Your Business Systems Without Replacing Everything

TL;DR

• Keep a working CRM, accounting system or POS responsible for the records and rules it already handles well.
• Start with one complete handoff that people currently perform manually, including corrections and cancellations.
• Give every important field and action one owner. Do not make every system writable in both directions by default.
• Test retries, duplicate events, outages and reconciliation before calling an integration finished.
• Use native connectors or middleware when they meet the workflow; build a custom layer only for gaps that justify owning more software.

Start with a handoff, not an architecture diagram

Suppose a service company uses a CRM for sales, a scheduling tool for delivery and accounting software for invoices. A salesperson marks a deal won. An administrator copies the customer and job into scheduling. Later, finance re-enters the invoice details. If the customer changes the date, someone has to remember which other systems need updating.

“Connect our CRM and accounting” is not yet a useful requirement. Start with one complete handoff: an approved deal becomes work, the right customer and job data reach scheduling, corrections propagate, completion triggers the agreed accounting action, and cancellation does not leave an active job or duplicate invoice behind.

That workflow tells you which data must move, which actions matter and where failure would hurt. The list of software products comes second.

Give every important fact one owner

The most important integration decision is not API versus webhook. It is who is allowed to decide the value.

Do not turn the integration layer into an accidental second CRM or accounting system. If two systems can both change the same field, define which change wins and why. Bidirectional synchronization is a requirement to justify, not a default feature.

The same word can mean different things in different products. “Completed” might mean the job finished in scheduling and the invoice paid in accounting. Copying the label without translating the meaning creates a clean-looking inconsistency.

Microsoft’s Anti-Corruption Layer pattern addresses this problem by placing a translation boundary between systems with different models or semantics. The layer can keep the external system unchanged while preventing its conventions from leaking into the rest of the application.

Choose the simplest connection that can pass the workflow

A native connector is not automatically better because it is prebuilt. A custom API is not automatically better because it is custom. The test is whether the method supports the required actions and can be operated when something goes wrong.

Map the data before mapping the endpoints

For every field that crosses the boundary, record the source system and identifier, destination field, owner of the value, conversion rule, transfer timing, meaning of blanks, correction behaviour and what happens when the destination rejects the value.

Stable identifiers matter. Matching customers by display name can merge different people or create duplicates when spelling changes. Preserve the source identifier and keep a traceable mapping between systems.

Design the failed transfer before the successful one

What if the destination is unavailable?

Decide whether the source action can continue and retry later or whether the user needs an immediate failure. Microsoft’s Retry pattern notes that retrying non-idempotent operations can repeat side effects when the first request succeeded but the response was lost.

What if the same event arrives twice?

Use a stable event or transaction identifier and record what has already been processed. Receiving the same “job approved” event twice should not create two jobs.

What if the transfer keeps failing?

Do not retry forever. Record the failed item, alert the responsible person and make the record available for investigation or replay after the cause is fixed.

Reconciliation is part of the integration

Monitoring tells you that a request failed. Reconciliation tells you that the systems still agree. For a critical workflow, periodically check business identifiers: every approved job that should have reached scheduling, every completed job that should have created an invoice, cancelled jobs still active downstream, duplicate records and items waiting for retry.

Do not rely only on totals. Ten jobs in each system do not prove they are the same ten jobs.

Worked example: connect CRM, scheduling and accounting

Hypothetical example. This is an acceptance exercise, not a Caemcore client result.

Suppose the CRM owns the customer and approved commercial terms. Scheduling owns the job date and operational status. Accounting owns invoices and payment status. The first release covers one branch and one job type.

1. Ordinary job. Approve a test opportunity and verify that exactly one scheduling job appears with the correct identifiers and that completion triggers the agreed accounting action once.
2. Correction. Change the date through scheduling and verify that an older value from the CRM cannot overwrite it.
3. Duplicate event. Replay the approval event and verify that a second job is not created.
4. Accounting unavailable. Use a controlled failure response and verify an unambiguous state, an alert and a safe retry path.
5. Reconciliation. Account for every expected record as synchronized, intentionally excluded or failed with a reason, then resolve and replay the failed item.

Passing these tests does not prove every future failure is covered. It does show that the operating behaviour has been designed, not only the connection setup.

When should you add a custom layer?

A custom integration layer becomes useful when several workflows need the same translation, monitoring or business rules, or when you want applications to depend on a stable internal model instead of every vendor’s field names.

Microsoft’s Anti-Corruption Layer guidance describes this adapter role and the extra maintenance and observability it creates. The layer is not free architecture. Use it when isolating external-system differences is worth owning another component.

It can also support gradual replacement. Microsoft’s Strangler Fig pattern describes moving selected functionality while old and new systems coexist. That can reduce cutover risk, but coexistence creates its own work: cross-system calls, shared data and a plan for which version handles each action.

When should you replace a system instead of integrating it?

Replacement deserves serious consideration when the current product cannot perform or expose an essential action, the vendor does not provide a supported alternative, and the smaller integration options leave the blocker in place.

• The required record cannot be read or changed through any supported interface.
• The product’s permission model cannot enforce a required access boundary.
• The business rule belongs in the core system and cannot be represented there.
• The available connection is too delayed or unreliable for the required operation.
• Maintaining the workaround costs more or creates more operational risk than replacing the constrained boundary.

“Everything is disconnected” is not enough evidence. Several systems may be the correct architecture if each owns a different job and the handoffs are reliable.

Write the integration brief before asking for a quote

1. Workflow. One ordinary case plus corrections and cancellations.
2. Ownership. Which system owns each important record and action.
3. Interfaces. Products, account plans, APIs, webhooks, exports and restrictions.
4. Freshness. Which updates must be immediate and which can wait.
5. Failure behaviour. What users see and what the system does when a dependency is unavailable.
6. Reconciliation. How missing, duplicate and conflicting records are found.
7. Permissions. Which service accounts and roles can perform each action.
8. Operating owner. Who receives alerts and coordinates vendor changes.
9. Acceptance tests. The flows that must be demonstrated before go-live.
10. Exit. Documentation, code or automation ownership, credentials and takeover process.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Do we need a central database to connect several systems?

Not necessarily. Some workflows can remain point-to-point, while reporting may benefit from a separate read model or warehouse. Add shared storage only when it solves a defined consistency, performance or reporting requirement. If data is copied, document which system owns the original value and how the copy is refreshed.

Should customer data sync both ways between CRM and accounting?

Only if both systems genuinely need to create or change the same fields. For each field, name the owner and define what happens when the non-owner has a different value. Many integrations are safer when one system writes and the other reads.

What if one of our systems has no API?

Check supported exports, scheduled files, vendor extension points or controlled database access before replacing the product. Screen automation can be a last resort, but it needs explicit monitoring and ownership because interface changes can break it. A missing API does not by itself prove the whole system should be replaced.

Can Zapier, Make or another integration platform replace custom development?

Sometimes. Use the simplest supported connection that meets the workflow, permissions, volume, recovery and monitoring requirements. Custom code becomes useful when the ready-made path cannot express the required business rules or operating controls. The tool choice follows the workflow rather than defining it.

How do we know an integration is ready to go live?

Rehearse an ordinary transaction, a correction, a duplicate event and an unavailable downstream system. Reconcile the source and destination records, verify alerts and recovery, and name who responds when the integration fails. Go-live acceptance should cover the failure paths the business cannot afford to discover accidentally.

Sources

• Microsoft Azure Architecture Center, Anti-Corruption Layer pattern. Checked 13 September 2026.
• Microsoft Azure Architecture Center, Asynchronous messaging options. Checked 13 September 2026.
• Microsoft Azure Architecture Center, Retry pattern. Checked 13 September 2026.
• Microsoft Azure Architecture Center, Strangler Fig pattern. Checked 13 September 2026.

The CRM, scheduling and accounting workflow is a hypothetical acceptance exercise, not a Caemcore client result.