Start with the failure, not the technology
“Our systems do not talk to each other” can describe several different problems: duplicate data entry, missing ownership, inconsistent records, an unsupported platform, or a workflow the current product was never designed to handle. The right decision depends on which failure is actually costing the business time, money, or control.
Map one important workflow from trigger to outcome. Mark every manual handoff, re-entry, delay, exception, and system of record. That gives you evidence for the decision instead of a general feeling that the technology is old.
The four tests
| Test | Integration is favored when | Replacement is favored when |
|---|---|---|
| Core fit | Each system performs its main job well. | The core workflow depends on workarounds the product cannot support. |
| Data ownership | There is a clear source of truth and usable integration access. | Records cannot be trusted, exported, governed, or reconciled reliably. |
| Operational risk | The platform is supported, secure, and stable enough to keep. | Support, security, performance, or compliance creates material risk. |
| Change cost | Connecting the systems solves the bottleneck without disrupting users. | Maintaining connectors and workarounds costs more than a controlled migration. |
Choose integration when the edges are broken
Integration is usually the practical first move when the CRM, accounting platform, scheduling tool, or operational product is sound on its own. A focused integration can remove duplicate entry, keep statuses synchronized, trigger follow-up, and give managers one reliable view without retraining the entire company.
Define the source of truth for every shared record before building. Decide what happens when a sync fails, which system may change a field, how duplicates are handled, and who sees an exception. Connecting two systems without those rules can move inconsistent data faster.
Choose replacement when the center is broken
Replacement becomes reasonable when the primary system cannot support the business process, depends on unsupported technology, blocks access to essential data, or creates unacceptable security and operating risk. The U.S. Government Accountability Office notes that legacy systems can increase maintenance costs and cybersecurity risk, and recommends modernization plans with clear milestones, defined work, and an explicit disposition for the legacy system.
Do not compare a replacement project only with the current software license. Include the cost of manual reconciliation, repeated data entry, incidents, delayed decisions, specialist maintenance, missed revenue, and every integration that exists only to compensate for the core system.
Use a phased migration when a big-bang change is too risky
A phased migration replaces one capability at a time while the existing system continues to operate. Microsoft’s Azure Architecture Center describes this as the Strangler Fig pattern: new components gradually take over functions until the old system can be retired. It lowers migration risk, but it also creates temporary complexity because old and new components must coexist.
- Select one business capability with clear boundaries and measurable value.
- Put a stable interface around the existing system and define data ownership.
- Build or move the selected capability and route only that work to the new component.
- Monitor errors, user adoption, cycle time, and reconciliation before moving the next capability.
- Retire the old function and its connector once the new path is proven.
What not to do
- Do not integrate indefinitely around a failing core. More connectors can hide the need for replacement while increasing dependency and support cost.
- Do not replace everything because one handoff is manual. A narrow integration may solve the valuable problem much faster.
- Do not start a migration without a retirement plan. AWS lists retain, retire, repurchase, replatform, refactor, and other strategies because not every component deserves the same treatment.
- Do not measure delivery by screens shipped. Measure fewer manual touches, shorter cycle time, lower error rate, and fewer unresolved exceptions.
A practical decision
Keep systems that perform their core job, connect only where the workflow needs reliable movement, and replace the smallest capability that genuinely blocks the operation. If the evidence still points to a full replacement, turn it into a sequence of controlled business changes rather than one large technical event.