Contents
Repeated data entry can suggest an integration problem, but the underlying issue may be a process or a system that no longer fits. Before connecting applications or replacing one, establish what needs to improve and whether the existing systems can support that outcome. Compare the complete transition and operating responsibilities for each option.
Locate the failure in the working process
Follow a representative task from start to finish. Record where people copy information, wait for approval, reconcile conflicting records or work outside the intended system. Ask which steps are necessary controls and which exist because the tools cannot exchange or represent the required information.
Describe the improvement in operational terms. Reducing repeated entry is different from changing approval rules or introducing a new service. An integration can move information between applications, but the proposed design must still explain who makes decisions and how exceptions are resolved.
Check whether the existing systems still fit
Identify the business capabilities each system provides and the constraints that matter. Review supported interfaces, data export, permissions, configuration and the supplier's current support arrangements. Confirm the actual capabilities available under your account and licence rather than assuming a product's general feature list applies.
If the core workflow works and the main difficulty is a well-defined handoff, investigate integration. If essential rules or records cannot be represented reliably, examine replacement or a redesigned boundary. Keep both options open until the important constraints have been tested.
Decide which system owns each fact
Name the authoritative source for key records and fields. Specify where changes are made, how identifiers match and what happens when two applications contain different values. Include deletion, corrections and historical records so the plan covers the full lifecycle rather than only creating new entries.
Ask who resolves mismatches and how they will see them. A connection that transfers ambiguous data faster can increase the reconciliation burden. Where ownership is unclear, settle the process decision before choosing a connector or estimating the build.
Compare the transition risk
For integration, examine failure recovery, duplicate prevention, access and the impact of upstream changes. Decide how operations continue when a connection is unavailable. Establish a bounded trial with controlled records and explicit reconciliation before expanding the flow.
For replacement, include migration, training, acceptance and the period when old and new systems may coexist. Define how records are reconciled at cutover and which recovery actions remain possible afterwards. Avoid comparing an integration estimate with a replacement estimate that omits the surrounding operational work.
Compare ongoing ownership as well as the build
Request estimates against the same outcome and operating period. Include licences, support, monitoring, supplier changes and the work needed to handle exceptions. Record assumptions separately, especially those dependent on access, data quality or a third party's behaviour.
Consider the organisation's capacity to maintain the result. A small integration may be appropriate when someone can own its alerts and reconciliation. A replacement may simplify part of the process while introducing migration and adoption responsibilities. Neither label establishes the lower total burden without a concrete plan.
Choose the next commitment from evidence
Summarise the process problem, tested constraints and expected improvement. Identify the smallest investigation that would resolve a decisive uncertainty: inspecting exports, exercising an API or trialling the target workflow with representative users. Give that investigation an output and a decision date.
Record why the selected option fits, what remains uncertain and which conditions would trigger a review. Use acceptance measures that reflect the operational task, such as correctly reconciled records and recoverable exceptions. Keep the decision connected to how the business will work after the change.
An integrate-or-replace exercise for order processing
A fictional distributor’s CRM and order system both work, but staff retype approved orders. Option A connects the approved-order handoff. Option B replaces the order system. For A, check supported write and lookup operations, field ownership, rejected orders and reconciliation. For B, check equivalent fulfilment rules, historic records, migration, staff training and the operating period when both systems coexist.
Suppose the existing system accepts an external reference and can report whether it has already processed it. A controlled integration trial may be the appropriate next step. If it cannot represent an essential approval state or a required correction, a connector may merely accelerate the wrong process. Test that limitation instead of selecting either option by interface age or product label.
Record complete one-off and recurring responsibility for both options on the same planning horizon. Include exception handling, licences, monitoring and exit arrangements. Agree which unresolved constraint determines the next decision. GOV.UK’s technology guidance is useful for considering existing systems and ownership cost; it is not a mandatory procurement rule for this fictional private business.
How this relates to Veda Software’s work
Powerleague’s supplier-facing ordering flow is relevant to examining a handoff around an established operation. It does not establish the interfaces or replacement decision for a CRM or ERP product.