Choose one event and assign ownership
Select one recurring handoff and define which system owns each important fact.
Guide
How to connect existing business software without replacing it
Replacement is not the only modernization strategy. Existing software can often remain in place while selected events and records move through a new integration layer.
Modernization path
Keep useful systems while repairing the handoffs between them.
Integration is a focused modernization strategy—not a promise to preserve inadequate software forever.
Inspect interfaces and map identifiers
Use supported APIs, webhooks, imports, exports, files, databases, or vendor services.
Define exceptions and prove the result
Handle missing data, duplicates, delays, approvals, destination failures, and reconciliation.
Replace only when integration is irresponsible
Blocked access, unacceptable security, unsupported software, poor exports, or fundamental process mismatch may justify replacement.
01
1. Choose one handoff
Do not begin with a goal to ‘integrate the company.’ Select one recurring event such as a new customer request, approved estimate, scheduled job, completed service, received payment, membership change, or document intake.
State the current manual steps and the desired outcome. This creates a testable boundary.
02
2. Decide which system owns each fact
Two systems may both contain a customer name, address, status, or balance, but they should not necessarily both be allowed to author every field. Define where the authoritative value originates and which systems receive copies for their own jobs.
Without ownership rules, two-way synchronization can create loops, conflicts, and unexplained overwrites.
03
3. Inspect supported integration points
Modern applications may provide APIs, webhooks, connector actions, scheduled reports, imports, exports, or database access. Older systems may still provide usable files, vendor services, email events, or controlled read access.
Use supported interfaces whenever possible. Screen scraping or fragile browser automation should be treated as a last resort with explicit maintenance expectations.
04
4. Map identifiers and data
The integration needs a way to recognize that records in separate systems refer to the same customer, job, order, or payment. Preserve source identifiers and define the matching rules before processing production data.
Map required fields, formats, allowed values, defaults, and transformations. Identify which missing values should stop the workflow and which can be corrected later.
05
5. Define exceptions and approvals
Not every record should pass automatically. The design should state what happens when a customer cannot be matched, an amount differs, a required field is missing, the destination is unavailable, or the action requires approval.
A correction queue can be more dependable than forcing every exception into automated guesswork.
06
6. Prove the end-to-end result
Test normal records, duplicates, missing information, delayed responses, and likely edge cases. Confirm the business outcome in the destination system and preserve enough evidence to trace what happened.
Launch gradually when the consequence is significant. Reconcile expected events against actual results after launch.
07
When replacement becomes the stronger choice
Integration should not be used to preserve software at any cost. Replacement may be appropriate when the system blocks necessary access, cannot protect or export data responsibly, is unsupported, creates unacceptable security risk, or fundamentally cannot support the business process.
The decision should compare operational disruption, migration risk, integration maintenance, user needs, and long-term ownership rather than focusing only on the purchase price.
FAQ
Frequently asked questions
Can two systems synchronize in both directions?
Yes, but two-way synchronization requires explicit ownership and conflict rules. It is often safer to define different authoritative fields or events rather than allowing both systems to overwrite everything.
What if the software only exports CSV files?
A scheduled export/import workflow may still be useful if the file is dependable, contains stable identifiers, and the delay is acceptable. File-based integration needs validation, duplicate handling, and clear processing status.
Can email be an integration trigger?
Yes, for some workflows. Email is less structured than an API event, so the design should account for formatting variation, attachments, duplicates, and missing messages.
Should we integrate before cleaning all our data?
The required level of cleanup depends on the workflow. You need enough consistency to identify and process the selected records safely. A focused cleanup and matching strategy may be part of the integration.
Sources
Sources and further reading
These references provide technical background. The recommendations on this page still depend on the actual systems, workflow, access, and operating risk.
- AWS: Application integrationBackground on integrating independently developed applications and retaining legacy systems when replacement is impractical.
- IBM: MiddlewareBackground on the software layer that supports communication and data management between applications.
Start with one handoff
Keep the software that works. Repair the handoff that does not.
The Integration Check identifies whether the current systems expose a dependable connection path.
Email Results InnovationsDo not send passwords, secrets, or sensitive customer records in the first message.